Pytorch: [RFC] 메모리 형식(일명 레이아웃이라고도 함) 지원

에 만든 2019년 04월 10일 · 68코멘트 · 출처: pytorch/pytorch

문제 설명

CNN 연산자는 텐서 차원의 표준 순서를 활용하고 의미론적 의미를 할당합니다. 오늘날 PyTorch의 2D 사례의 경우 torch.nn.Conv2d에 대한 입력은 NCHW 순서의 4d 텐서여야 합니다..

성능상의 이유로 특정 작업에서 액세스하는 메모리가 연속적으로 배치되고 지역성이 더 잘 활용되도록 차원을 다르게 재정렬하는 것이 종종 유리합니다. 가장 일반적인 옵션은 치수를 끝으로 이동하는 것입니다 - NHWC. 한 차원을 블록으로 바둑판식으로 배열하는 훨씬 더 복잡한 메모리 형식이 있을 수 있습니다..

이를 활용하는 라이브러리의 예는 다음과 같습니다.

cudnn은 NHWC의 Volta에서 더 빠른 성능을 제공합니다.
fbgemm 및 qnnpack은 NCHW를 지원하지 않습니다.
libxsmm는 NCHW를 지원하지만 성능 저하가 50%(IIRC)와 비슷합니다.

문제는 차원 순서를 변환하는 것 자체가 비용이 많이 들기 때문에 여러 CNN 작업이 연속으로 수행되는 경우(예: conv(relu(conv))) ) 다른 메모리 형식으로 한 번 변환 하고 작업을 수행하고 재정렬하는 것이 좋습니다. 뒤.

따라서 PyTorch가 다양한 차원 순서를 인식하고 Eager 모드와 JIT 모드 모두에서 작업 간에 다른 메모리 형식을 가진 텐서를 전달할 수 있도록

우리는 다음을 표현할 수 있는 API를 구축하기 위해 노력합니다.

Eager 및 JIT의 PyTorch에 있는 다른 메모리 형식(처음에는 차원 순서만)을 가진 텐서. 차단된 레이아웃은 우선 순위가 낮지만 여전히 좋습니다.
메모리 형식 쿼리 및 변경을 위한 사용자 노출 API
다른 메모리 형식을 가진 입력 텐서를 처리하고 해당하는 더 빠른 구현으로 라우팅할 수 있는 핵심 CNN 작업
JIT 패스의 메모리 형식을 추론하고 최적화하는 기능

용어 : 위의 문제는 종종 "layout"(mxnet), "data_format"(tf), "image_format"(keras), "order"(caffe2)라고 합니다. 우리는 PyTorch에서 "memory format" 또는 "memory_format"이라는 이름을 사용할 것을 제안합니다. "레이아웃"이라는 이름은 불행히도 PyTorch에서 'strided' 대 'sparse_coo' 값을 사용하므로 이름 지정 옵션을 사용할 수 없습니다.

영향을 받는 운영자

다음 연산자는 최소한 메모리 형식을 인식해야 합니다. 정확한 결과를 생성하는 것 외에도 기본 라이브러리에서 최상의 성능 을 제공하고 명시적으로 지정된 사용자 의도를 전파하기 위해 출력의 메모리 형식 을

회선
다양한 풀링
배치 놈, 레이어 놈, 인스턴스 놈 (일반적으로, 놈에 상관없이)
업샘플링/보간
피쳐 드롭아웃
softmax 수준은 낮음 - 차원을 수동으로 지정할 수 있지만 효율적인 구현은 암시적 nchw 레이아웃에 대해서만 존재합니다.
심
요소별(단항 및 이진) 연산
메모리 형식을 상속하는 텐서의 생성자(예: empty_like).

API 및 동작 변경 사항

PyTorch에서 메모리 형식의 개념 정의:

torch.memory_format.channels_first 와 같은 상수입니다. 유형이 지정되지 않았으며 임의의 비교 가능한 객체가 될 수 있습니다(enum으로 시작할 가능성이 높지만 나중에는 명명된 텐서의 개념과 상호 운용되는 다른 객체가 될 수 있음)
- 대안: torch.channels_first 직접 사용
값은 channels_first 및 channels_last (더 적은 수의 상수 허용).
1D 이미지 / 3D 텐서의 경우 값은 평균 NCW, NWC, 2D 이미지 / 4D 텐서 - NCHW, NHWC, 3D 이미지 / 5D 텐서 - NCDHW, NDHWC

Tensor에 다음 메서드를 추가합니다.

x.is_contiguous(torch.memory_format.channels_first)
x.to(memory_format=torch.memory_format.channels_first)

참고 : 지금은 x.get_memory_format() 기능이 없고 명시적 검사만 가능합니다. 가능한 구현 범위가 더 넓습니다. 우리는 그것을 추가하고 싶을 수도 있습니다.

텐서 의미론적 레이아웃은 항상 동일하게 유지됩니다 - NCHW! x.size() 항상 (n,c,h,w) 반환합니다.

작업은 메모리 형식 동작을 유지합니다.

컨볼루션, 풀링 등(위 참조)은 입력과 동일한 메모리 형식 으로 출력을 반환하고 내부적으로 최상의 구현으로 디스패치합니다.
단항 요소별 연산은 동일한 메모리 형식을 유지하고 인접한 텐서만큼 빠르게 실행해야 합니다.
이진 요소별 연산은 메모리 형식을 유지하는 데 있어 합리적인 보장을 제공합니다. 더 광범위하게 정의할 수 있지만 최소값은 다음과 같습니다.
- NHWC + 스칼라 → NHWC
- NHWC + 열 벡터 → NHWC
핵심 CNN 연산에 대한 역방향 연산은 순방향 경로에서와 동일한 메모리 형식을 유지합니다. (출력에 대한 수신 그라디언트가 다른 메모리 형식일 수 있기 때문에 명시적으로 적용해야 할 수도 있습니다.)

메모리 형식은 직렬화/역직렬화를 통해 보존되는 텐서의 속성입니다(텐서가 매개변수인 경우).

스트라이드 구현

오늘날 PyTorch의 Tensor에는 논리적 텐서가 메모리에 배치되는 방식을 지정하는 strides 개념이 있습니다. 특히 각 텐서는 sizes 와 같은 길이의 strides 벡터를 가집니다. (i1, i2, .., ik) 논리적 인덱싱에서 요소를 인덱싱하려면 보폭으로 내적을 수행하고 offset + i0*stride0 + i1*stride1 + ... * ik * stridek 에서 메모리를 찾습니다. 따라서 인접한 텐서는 크기의 누적 곱이 역전되는 보폭을 갖습니다. 예를 들어 (n,c,h,w) 크기의 4D 텐서에는 (c*h*w, h*w, w, 1) 있습니다.

스트라이드는 논리적 기본 NCHW 순서를 유지하면서 물리적으로 다른 메모리 형식(차원 재정렬)을 나타내는 데 사용할 수 있습니다. 다음과 같이 메모리 형식 변환에 대한 효과적인 정의를 제공합니다.

# implementation of x.to(channels_last)
def to_mem_format_nhwc(x):
    return x.permute(0,2,3,1).contiguous().permute(0,3,1,2)

# implementation of x.to(channels_first)
def to_mem_format_nchw(x):
    return x.contiguous()

NHWC 형식에서 보폭 벡터는 (c*h*w, 1, c*w, c) 입니다. 따라서 메모리 버퍼에서 가중치는 NHWC에 대해 연속적인 순서입니다.

Strides는 테스트에 사용할 수 있습니다.

def is_nhwc_contiguous(x):
    return x.permute(0,2,3,1).is_contiguous()

# or alteratively
def is_nhwc_contiguous(x):
    n,c,h,w = x.size() # in any case the sizes remain in NCHW order
    return x.stride() == (c*h*w, 1, c*w, c)

def is_nchw_contiguous(x):
    return x.is_contiguous()


# operator implementations can just check contiguity and carry on directly on data pointer
def my_sample_op(x):
    if x.is_contiguous(nhwc):
        float* p = x.data();
        # Do we need to go to c++ here? 
        # can we have an example in python?
        n,c,h,w = x.size()
        # operate on `p` as it's guaranteed to be (n,h,w,c) array
        y=my_nhwc_op(p)
        # Do we need to convert the layout of y?

    else:
        # Need to convert x to nhwc layout
        x = x.permute(0,2,3,1).contiguous()
        float *p = x.data();
        # Is this needed?
        y = my_nhwc_op(p)
        return y.permute(0,3,1,2).contiguous()

이 접근 방식의 장점 :

새로운 최상위 아이디어나 API 매개변수를 추가하지 않고 기존 PyTorch 개념의 보폭 활용
표준 NCHW 순서로 텐서의 논리적 동작을 유지합니다.
입력 차원의 임의 재정렬에 대해 작동합니다.
기존 직렬화 루틴은 이미 텐서의 보폭을 유지합니다.
다양한 메모리 레이아웃에서 작업하기 위해 많은 작업을 재사용하는 기능

단점 :

.contiguous() 호출하는 것은 NCHW로 전환하는 것과 동일하며 사용자 또는 작업 중 하나 내부에서 우연히 발생할 수 있습니다.
- 운영자가 메모리 형식을 보존하는지 확인하려면 운영자에 대한 명시적 감사가 필요합니다.
차단/타일 형식에서는 작동하지 않습니다. 다른 접근 방식이 필요합니다.
- PyTorch에서 일급 시민으로 추가하는 것을 고려할 수 있지만 훨씬 더 큰 변화입니다.
- 대안은 불투명 핸들(예: MKLDNN 텐서)로 처리하는 것입니다.
기본 구현의 성능 특성이 최종 사용자에게 덜 명확함

가장 큰 잠재적 문제는 불분명한 사용자 의도 입니다. 사용자가 정말로 다른 메모리 형식을 원했는지 아니면 입력 텐서가 우연히 이런 식으로 스트라이드(stride)되었는지 구별할 방법이 없습니다. 특히, 기존 작업의 동작 변경으로 이어집니다. 오늘날 컨볼루션은 입력이 임의의 스트라이드인 경우에도 NCHW 연속 텐서를 생성할 수 있습니다. 새로운 세계에서는 입력을 NHWC로 인식하여 NHWC도 반환할 수 있습니다. 의미 체계는 변경하지 않지만 디버그하기 어려운 성능 문제로 이어집니다. 가능한 해결책은 사용자 지정 memory_format 플래그를 사용하여 텐서에 명시적으로 태그를 지정하고 이 주석(스트라이드 외에)만 따르는 것입니다.

위의 문제를 해결하기 위해 초기 제안은 텐서에서 수행된 마지막 to(memory_format) 호출을 기록하는 "소프트" 메모리 형식 태그를 텐서에 도입하는 것입니다. 운영자는 이 주석을 출력에 전파해야 합니다. 주석은 "소프트"이므로 불일치 주석에 대한 하드 오류가 발생하지 않고 프로파일링 모드에서 경고가 생성됩니다.

연산자 구현

기존 운영자의 서명은 변경되지 않습니다. 운영자는 운영자 내부에서 하드 코딩된 디스패치를 수행하여 더 빠른 구현으로 라우팅할 수 있습니다. 구현이 불가능한 경우 다른 메모리 형식을 통한 왕복이 가능합니다. 대안은 오류 메시지를 발생시키는 것입니다.

def maxpool(x: Tensor):
    if x.is_contiguous(torch.layout.NHWC):
        return max_pool_impl_nhwc(x)
    return max_pool_impl_default(x.contiguous())

'conv_nhwc'와 같은 별도의 연산자를 만드는 대신 'conv'와 같은 단일 기호를 사용하여 JIT IR의 연산자를 참조하는 것이 좋습니다. 그 이유는 단순성과 의미론적 표현 수준에서 IR을 유지하기 때문입니다.

요소별 연산

element-wise와 같은 핵심 작업이 메모리 형식을 유지하고 효율적임을 보장해야 합니다.

단항 연산은 일반적으로 메모리 블록이 "밀도"인지 여부, 즉 요소가 간격이 없는 영역에 걸쳐 있고 각 메모리 위치가 정확히 한 번 사용되는지 여부를 확인하여 처리할 수 있습니다. 간단한 알고리즘으로 검증 가능

def is_dense_format(x):
    p = 1
    for s, d in sorted(zip(x.stride(), x.size())):
        if s != p:
            return False
        p *= d
    return True

def my_unary(x):
    if is_dense_format(x):
        return contig_memory_impl(x.data(), x.numel())
    return default_strided_impl(x)

# is_dense_format can be used in implementations of e.g. empty_like too

성능 도구

디버깅 성능을 위해 프로파일러에 다음 지원을 추가해야 합니다.

프로그램에서 실제 메모리 재정렬이 발생하는 위치 확인 - 즉 .contiguous()에 대한 호출 추적
호출된 구현 추적
예를 들어 바이너리 연산("소프트" 주석이 유용한 경우)에서 메모리 형식 변경에 대한 경고를 발행합니다.

이 기능은 주문형 프로파일링 도구에 구축할 수 있습니다.

Autograd 처리

역방향 패스가 정방향과 동일한 메모리 형식으로 실행되어야 한다고 예상하는 것이 논리적입니다. 들어오는 그라디언트가 임의적으로 스트라이드될 수 있으므로 항상 자동으로 발생하지는 않습니다. 따라서 정방향 패스는 메모리 형식을 명시적으로 인식하고 autograd 클로저에 저장하고 역방향 기능 전에 grad 텐서에 적용해야 합니다.

가능한 구현:

def conv_backward(input, weight, grad_output, grad_weight, grad_input):
  if input.is_contiguous(torch.memory_format.channels_last):
    grad_output = grad_output.to(torch.memory_format.channels_last)
    return conv_backward_nhwc(...)
  else:
    grad_output = grad_output.contiguous()
    return conv_backward_nchw(...)

JIT에서의 표현

현재 제안은 다음과 같습니다.

유형 주석의 메모리 형식에 대한 일급 처리는 아직 없습니다. 대신 메모리 형식을 조작하는 패스에 필요한 모양으로 lookside 맵을 유지할 수 있습니다.
값별 형식 주석을 생성하는 추론 패스(shape_inference와 유사)
최적의 성능을 위해 필요한 to(memory_format) 호출을 삽입해야 하는 위치를 찾는 메모리 형식 변환 패스(수동 또는 자동)

집행 목적으로 assert x.is_contiguous(channels_last) 와 같은 명령문을 사용할 수도 있습니다.

참고: 특정 장치에 선호되는 메모리 형식 조합이 있다는 정보를 저장할 위치에 대한 질문이 있습니다(예: x86의 qconv는 NHWC만 구현하는 fbgemm 경로). 한 가지 옵션은 op 등록 수준에 두는 것이지만 메모리 형식 주석은 더 많은 부가 정보처럼 느껴집니다. 선호하는 메모리 형식 및 관련 휴리스틱을 나타내는 전역 맵을 JIT 패스의 어딘가에 유지 관리하는 것으로 시작할 수 있습니다. 어수선하면 등록 기반 메커니즘으로 전환할 수 있습니다.

Beyond: 차단된 레이아웃

더 복잡한 텐서 패킹을 추가하기로 결정함에 따라 높은 구현 비용과 복잡성으로 인해 1급 PyTorch 텐서를 사용하는 것이 타당하지 않을 수 있습니다. 두 가지 대안이 가능합니다.

사용자 정의 C 유형 바인딩과 같은 불투명한 표현. 성능 최적화 측면에서 다양성이 더 높은 추론에서 패킹을 위해 선택하는 옵션입니다.
MKLDNNTensor와 같은 일급 텐서 유형으로, 일부(전부는 아님) 작업이 이 새로운 유형에 바인딩됩니다.

또 다른 대안은 핵심 PyTorch Tensor 클래스에서 차단/타일링에 대한 기본 지원을 구현하는 것입니다.

명명된 텐서 관계

NamedTensor 에 대한 기존 제안은 텐서에 대한 유형 검사 메커니즘으로 구성되어 있습니다. 현재 차원 이름에 의미론적 의미를 할당하지 않습니다. 따라서 활성화 텐서의 의미를 추론하는 유일한 방법은 미리 결정된 NCHW 형식을 계속 사용하는 것입니다. NamedTensor와 현재 제안을 직교하게 만듭니다.

일부 이름의 의미(예: "채널", "너비")를 기꺼이 지정하려는 경우 운영자는 이 정보를 활용하여 더 빠른 구현으로 라우팅할 수 있습니다. 입력 텐서가 논리적으로 NHWC(오늘날과 같은 NCHW가 아님) 메모리 형식을 갖기 때문에 의미론적 변화가 될 것입니다.

선행 기술

TensorFlow는 data_format 매개변수를 통해 운영자 수준에서 NHWC와 NCHW를 모두 지원합니다. 허용되는 값은 4차원 입력의 경우 ("NHWC", "NCHW"), 5차원 입력의 경우 ("NDHWC", "NCDHW") 또는 입력과 무관한 channels_first / channels_last 입니다. 차원. 매개변수 설정을 올바르게 처리하는 것은 사용자에게 달려 있습니다. 즉, 텐서에 의해 자동으로 추적되지 않습니다.

Caffe2이 매개 변수가 호출 호출 order 보다는 data_format ,하지만 여전히 명시 적으로 개별 운영자 수준에서 적용합니다.

부록: 고려되는 기타 옵션

리트머스 질문: 다음 코드는 무엇을 인쇄합니까: tensor_in_nhwc_layout.size(1) - 채널 수(PyTorch의 기본값은 NCHW이기 때문에) 또는 높이(위치 1의 NHWC 레이아웃에 있기 때문에).

이 답변을 기반으로 몇 가지 옵션이 가능합니다.

옵션 A - 스트라이드(위에 제시됨). Tensor 레이아웃은 완전히 내부 표현입니다. 구현과 마찬가지로 보폭으로 가장 편리하게 수행됩니다.
- .size(1)은 "채널"을 반환하지만 내부 메모리는 다르게 배치됩니다.
- 장점: 모델의 코드를 변경하지 않습니다. 내 모델은 여전히 직접 차원 산술을 수행할 수 있습니다. 실제로 공개 API 변경 사항은 없습니다.
- 단점: strides 구현에서 많은 연산자가 .contiguous()를 호출하고 실수로 레이아웃을 다시 되돌릴 수 있습니다.
- 단점: 사용자 관점에서 수익률 보장이 무엇보다 중요한지 이해해야 합니다. 이 IMO는 보폭 전용 접근 방식을 제거합니다. 왜냐하면 작업이 반환될 형식을 이해하기가 매우 어려워지고 "내 보폭을 무시하고 실제로 NCHW에 인접한 것을 반환하십시오"라고 말하는 API가 없기 때문입니다. 이는 위의 제한 사항에 추가됩니다.
옵션 B - 명시적 NHWC 텐서. 사용자가 차원 순서가 다른 텐서를 명시적으로 조작하지만 텐서 자체는 이에 대해 아무것도 모릅니다. 사용자가 기대하는 것을 파악하려면 운영자 수준에서 주석이 필요합니다.
- .size(1)는 "높이"를 반환합니다.
- 장점: 마술이 없고 매우 예측 가능
- 단점: 한 레이아웃에서 다른 레이아웃으로 모델을 변경하는 것은 .size() 및 .reshape()에 대한 모든 액세스를 추적해야 하는 복잡한 작업이 됩니다(또는 API에서 명시적으로 만들어야 합니까?)
옵션 B' - 레이아웃 플래그가 있는 명시적 NHWC 텐서 . 위와 동일하지만 텐서에 주석을 추가하여 작업이 구현에서 소비하는 의미론적 레이아웃을 표시할 수 있습니다. 그러면 운영자 수준 주석이 필요하지 않습니다. 운영자는 입력의 레이아웃 플래그를 기반으로 디스패치를 수행할 수 있습니다.
옵션 C - 명명된 Tensor . ( https://docs.google.com/document/d/1ynu3wA2hcjwOtEng04N904gJjEbZWcINXO_ardX6hxc/edit#heading =h.2gbe5xpga3w9)
- .size(1)는 "높이"를 반환하지만 우리는 사람들에게 이 API를 사용하지 말고 대신 .size('channel')를 사용하도록 요청합니다.
- 장점: 매우 명시적이며 사용자가 원하는 것
- con: 전환 문제가 해결되지 않으면 레이아웃 인식으로 작성된 모든 코드에서 명명된 텐서를 사용하도록 강제해야 합니다. 그렇지 않은 경우 - 위와 동일한 문제가 적용됩니다.
옵션 D-레이아웃은 불투명한 텐서 유형 입니다. MKLDNN 또는 SparseTensor - 다른 DispatchID를 가진 별도의 텐서 유형을 취급하는 것처럼 NHWC를 취급합니다. 옵션 A와 비슷하지만 기본 동작에 대해 서로 다른 절충안이 있습니다. 구현되지 않은 작업은 NCHW로 되돌리는 대신 실패합니다.
- .size(1)은 여전히 "채널"을 반환합니다.
- 장점: 마술이 없고 명시적이며 별도의 디스패치가 운영자가 원하는 것을 결정할 수 있도록 합니다.
- 장점/단점: 필요한 모든 연산자는 다른 레이아웃에서 구현해야 합니다. 일부 연산이 누락된 경우 사용자는 지원되지 않는다는 명시적 오류가 발생합니다.
- 단점: 예상 결과를 예측하기 어렵기 때문에 뷰와 같은 많은 작업을 금지해야 할 것입니다.

internals mkldnn triaged

출처

dzhulgakov

👍9 ❤2

가장 유용한 댓글

BTW 왜 우리는 layout 집착하는 대신 새로운 개념을 만들어야 합니까? 희소 표현은 "channels_last"와 같은 레이아웃 개념이 잘 정의되어 있지 않다고 생각하므로 memory_formats * layouts 의 제품을 나타낼 필요가 없습니다( layouts 는 현재 사용을 나타냅니다. ), 하지만 memory_format + layouts 사용하면 이전과 동일한 인수를 사용하는 것이 좋습니다. 나에게 그것은 더 짧고 더 좋으며 팩토리 서명을 수천 개의 인수로 확장하는 것을 피할 수 있습니다.

apaszke 에 2019년 06월 27일

👍2

모든 68 댓글

empty_like 에는 한 가지 문제가 있습니다. 현재 정의된 의미는 모든 보폭 정보를 삭제한다는 것이므로 레이아웃을 유지하고 BC가 될 수 없습니다.

ezyang 에 2019년 04월 11일

👍1

@VitalyFedyunin 은 .contiguous() 및 torch.memory_layout 비트를 구현하도록 등록되었습니다.

ezyang 에 2019년 04월 11일

한 가지 질문 - (n, c, h, w) 크기의 4D 텐서 x (n, c, h, w)

x = torch.randn(n,c,h,w)
# x.size(): (n, c, h, w)
# x.stride(): (c*h*w, h*w, w, 1)

우리는 이상한 순열을 가지고 있습니다

y = x.permute(0, 3, 1, 2)
# y.size(): (n, w, c, h)
# y.stride(): (c*h*w, 1, h*w, w)

이제 NHWC 형식에 대해 연속적인지 확인합니다. 아래와 같은 논리에 따라

def is_nhwc_contiguous(x):
    return x.permute(0,2,3,1).is_contiguous()

# or alternatively
def is_nhwc_contiguous(x):
    n,c,h,w = x.size() # in any case the sizes remain in NCHW order
    return x.stride() == (c*h*w, 1, c*w, c)

두 경우 모두 is_nhwc_contiguous(y) 는 True를 반환합니까?

uyongw 에 2019년 04월 13일

이것은 맞습니다. 그러나 복사, to 및 유사한 작업 중에 앞뒤로 변환을 피하기 위해 보폭에만 릴레이할 수 없습니다.

VitalyFedyunin 에 2019년 04월 14일

strides의 순서가 메모리 형식과 같으면 어떻게 될까요? 4D 텐서를 예로 들어보겠습니다. 텐서를 설명하기 위해 sizes , strides 및 stride_indexes .

의 크기 (N, C, H, w)
물리적 순서에 따른 보폭 , 즉

형식이 nchw인 경우 (n, c, h, w)의 보폭
형식이 nhwc인 경우 (n, h, w, c)의 보폭.

stride_indexes 는

(0, 1, 2, 3) 형식이 nchw인 경우
(0, 2, 3, 1) 형식이 nhwc인 경우.

nchw 형식의 경우 이전과 동일합니다. nhwc의 경우 비슷할 것입니다.

def is_nhwc_contiguous(x):
     n,c,h,w = x.size()
     return x.stride() == (h*w*c, w*c, c, 1)

def is_nchw_contiguous(x):
    n,c,h,w = x.size()
    return x.stride() == (c*h*w, h*w, w, 1)

def is_nchw_format(x):
    return x.stride_index() == (0, 1, 2, 3) 

def is_nhwc_format(x):
    return x.stride_index == (0, 2, 3, 1)

def is_contiguous(x):
    if (is_nchw_format(x)):
        return is_nchw_contiguous(x)
    else if (is_nhwc_format(x)):
        return  is_nhwc_contiguous(x)
    else:
        warning_not_support()

# or, to use stride_index
def is_contiguous(x):
    return x.stride() == (x.size[x.stride_index[1]]*x.size[x.stride_index[2]]*x.size[x.stride_index[3]], x.size[x.stride_index[2]] * x.size[x.stride_index[3]], x.size[x.stride_index[3]], 1)

이것은 또한 차단된 형식을 지원하도록 확장될 수 있습니다. nChw16c를 예로 사용합니다.

sizes: (n, c, h, w)
block_sizes: (n, c/16, h, w, 16)
strides: strides of (n, c/16, h, w, 16)
stride_indexes: (0, 1, 2, 3, 1)  # assume blocked dimension is always in dense (i.e. on the right side of major dimension)

자세한 내용은 나중에 자세히 알아볼 수 있습니다.

uyongw 에 2019년 04월 15일

nchw 연속 텐서만 허용하는 OP의 경우 여기에서 약간의 작업이 필요할 것입니다.

또는 프로토타입을 약간 변경할 수도 있습니다.

def is_contiguous(format=nchw):
    ...
def contiguous(format=nchw)
    ...

따라서 기본적으로 nchw만 연속적이라고 가정합니다. 이런 식으로 해당 OP를 다시 작성할 필요가 없으며 자동으로 nchw로 재정렬됩니다.

uyongw 에 2019년 04월 15일

우리는 다음을 표현할 수 있는 API를 구축하기 위해 노력합니다.
Eager 및 JIT의 PyTorch에 있는 다른 메모리 형식(처음에는 차원 순서만)을 가진 텐서. 차단된 레이아웃은 우선 순위가 낮지만 여전히 좋습니다.
메모리 형식 쿼리 및 변경을 위한 사용자 노출 API
다른 메모리 형식을 가진 입력 텐서를 처리하고 해당하는 더 빠른 구현으로 라우팅할 수 있는 핵심 CNN 작업
JIT 패스의 메모리 형식을 추론하고 최적화하는 기능

좋은 제안! 내 이해가 올바른지 확인하겠습니다(MKL-DNN 형식 처리에 대한 제안 포함):

이 제안을 "형식" 클래스로 구현했다고 생각할 수 있습니다. API 쿼리 및 변경을 가상으로 제공하는 한 MKL-DNN 복합 형식에 맞는 상속/확장을 수행할 수 있습니다. 또는 형식 처리를 위한 프레임워크를 제공하는 한 다른 방법을 사용하여 중요한 세부 사항을 우리에게 전가합니다.

OP 구현에 대해 각 OP는 성능을 최대화하는 선호 형식과 작동하는 호환 형식을 가질 수 있습니다. 요소별 연산자(또는 더 일반적으로 말하면 메모리 제한 OP)는 기본 설정이 없다고 가정합니다. OP는 "형식" 개체를 사용하여 결과 텐서를 생성합니다. 이 형식 개체는 기본 pytorch 기대치와 호환되는 쿼리/변경 의미 체계를 보장할 뿐만 아니라 최적화된 함수의 일련 번호(예: conv2d(ReLU(conv2d)))로 호출되는 경우 특정 형식을 처리할 수 있습니다. 사례)

CaoZhongZ 에 2019년 04월 15일

@uyongw 첫 번째 예에 대해 좀 더 명확히 하고 싶습니다. "나는 NCHW 텐서를 가지고 있는데, 그것을 이상한 방식으로 조옮김했습니다. 그래서 지금은 NWCH처럼 보입니다. 이제 NHWC가 연속적인지 알고 싶습니다." 그러나 그것은 잘못된 관점입니다. 더 나은 공식은 "나는 NHWC 텐서를 가지고 있으며 NCHW 텐서로 전치했습니다."입니다.

다르게 말하면 텐서의 물리적 차원에는 본질적인 의미가 없습니다(보폭을 무시할 때). 보폭과 관련하여 참조하는 방법을 고려할 때만 의미를 부여합니다.

텐서를 설명하기 위해 크기, 보폭 및 stride_indexes가 있습니다.

나는 stride_indexes 가 문제에 대해 생각하는 편리한 방법이라고 생각하지만, strides와 엄격하게 중복됩니다. true strides.) @VitalyFedyunin 과 저는 strides 자체에서 정보를 재구성하는 것이

따라서 기본적으로 nchw만 연속적이라고 가정합니다.

네, 제가 읽은 계획입니다.

ezyang 에 2019년 04월 15일

@CaoZhongZ

이 제안을 "형식" 클래스로 구현했다고 생각할 수 있습니다. API 쿼리 및 변경을 가상으로 제공하는 한 MKL-DNN 복합 형식에 맞는 상속/확장을 수행할 수 있습니다. 또는 형식 처리를 위한 프레임워크를 제공하는 한 다른 방법을 사용하여 중요한 세부 사항을 우리에게 전가합니다.

나는 그것이 제안에 대한 정확한 설명이라고 생각하지 않습니다. 여기서 제안하는 메모리 레이아웃 지원은 스트라이드로 표현할 수 있는 레이아웃일 뿐입니다. 이 방법으로 표현할 수 없는 모든 것(예: 블록 레이아웃)은 이 방법으로 작동하지 않으며 더 무거운 "레이아웃" 메커니즘에 의해 지원되어야 합니다.

ezyang 에 2019년 04월 15일

다르게 말하면 텐서의 물리적 차원에는 본질적인 의미가 없습니다(보폭을 무시할 때). 보폭과 관련하여 참조하는 방법을 고려할 때만 의미를 부여합니다.

부분적으로 동의합니다 :-) 그러나 이 특정한 문제에 대해서는 아닙니다. 이미 nhwc 텐서가 있다고 가정해 보겠습니다. 그런 다음 nwhc로 변경합니다. nhwc로 더 순열한 다음 contiguous()를 수행하고 싶습니다. 그러나 나는 그것을 이미 연속적으로 얻었습니다. 혼란스럽지 않습니까?

나는 stride_indexes가 문제에 대해 생각하는 편리한 방법이라고 생각하지만, stride와 엄격하게 중복됩니다. 왜냐하면 당신이 말하는 모든 것은 "이 (역?) 순열을 보폭에 적용하고 그것을 진정한 보폭으로 취급하기 때문입니다.)

IMHO, nhwc(물리적)에 보폭이 있는 경우 보폭이 중복되지 않습니다. 크기(논리)가 있는 올바른 매핑이 필요하기 때문입니다. 그렇지 않으면 실제 순서를 말할 방법이 없습니다.

BTW 역 매핑을 사용하는 더 간단한 접근 방식이 있습니다. nchw의 경우 (0, 1, 2, 3)이고 nhwc의 경우 (0, 2, 3, 1) 대신 (0, 3, 1, 2)입니다. 즉, stride_index 자체도 항상 NCHW입니다. 그러나 문제는 nChw16c 또는 OIhw16i16o와 같은 차단된 형식으로 확장할 수 없다는 것입니다.

uyongw 에 2019년 04월 15일

차단된 형식에는 완전히 다른 연산자 구현 집합이 필요합니다. 이러한 이유로 우리는 정의상 모든 기존 연산자와 친숙하고 동일하거나 더 나은 성능으로 작동하는 '메모리 형식'과 혼합하지 않는 것을 선호합니다.

VitalyFedyunin 에 2019년 04월 15일

부분적으로 동의합니다 :-) 그러나 이 특정한 문제에 대해서는 아닙니다. 이미 nhwc 텐서가 있다고 가정해 보겠습니다. 그런 다음 nwhc로 변경합니다. nhwc로 더 순열한 다음 contiguous()를 수행하고 싶습니다. 그러나 나는 그것을 이미 연속적으로 얻었습니다. 혼란스럽지 않습니까?

일부 용어를 구어체로 사용하고 정확성이 필요하기 때문에 귀하의 예를 이해하기 어렵습니다. 말씀하신 내용을 제가 해석하는 방법은 다음과 같습니다.

이 제안에 따라 "nhwc" 텐서는 "물리적 레이아웃이 NHWC이지만 논리적 레이아웃이 NCHW가 되도록 스트라이드된 텐서"입니다.
"(논리적 레이아웃이 NCHW인 텐서) 텐서를 (논리적 레이아웃) NWHC로 치환"하는 것은 y = x.permute(0, 2, 3, 1) 를 실행하는 것입니다. 왜냐하면 물리적 레이아웃이 아니라 논리적 레이아웃을 치환하고 있기 때문입니다. (원래 게시물에서 순열 x.permute(0, 3, 1, 2) 을 언급했기 때문에 이것이 의미하는 바가 아니라고 생각합니다.
그런 다음 (논리적 레이아웃) NWHC 텐서를 (논리적 레이아웃) NHWC로 추가 순열은 순열 z = y.permute(0, 2, 3, 1) 을 적용하는 것입니다. 이제 논리적 레이아웃이 물리적 레이아웃과 일치하는 텐서가 있습니다. 이것은 우리가 z.contiguous() 묻는다면 우리는 참이 될 것이라는 것을 의미합니다(그리고 혼란스럽게도 z.contiguous(memory_layout=NCHW) 도 참이 될 것입니다.) 그러나 NHWC 연속적이지는 않을 것입니다.

나는 이것이 당신이 염두에 둔 예라고 생각하지 않습니다. 이 경우 "순열"이 의미하는 바에 대해 더 정확해야 합니다.

IMHO, nhwc(물리적)에 보폭이 있는 경우 보폭이 중복되지 않습니다. 크기(논리)가 있는 올바른 매핑이 필요하기 때문입니다. 그렇지 않으면 실제 순서를 말할 방법이 없습니다.

이 제안의 핵심입니다 : 논리적 인 레이아웃으로 우리 특권 NCHW, 항상. 따라서 내가 모르는 4D 텐서가 있는 경우 논리적 레이아웃이 NCHW라고 가정 합니다. 그것은 모호성을 제거합니다. 논리적 레이아웃이 NCHW가 아닌 텐서를 처리하고 싶다면 명시된 API가 삶을 조금 어렵게 만든다고 생각합니다.

ezyang 에 2019년 04월 15일

@dzhulgakov

작업은 메모리 형식 동작을 유지합니다.

물리적 NHWC 텐서가 순전히 스트라이드를 통해 발생할 수 있는 경우 메모리 형식 태그가 있을 때만 메모리 형식을 보존하도록 하지 않는 한 이것은 기술적으로 BC 깨는 것입니다. 제안이 현재 무엇을 제안하고 있는지 잘 모르겠습니다.) 이것이 실제로 실제로 누군가의 코드를 손상시키는지 확실하지 않습니다.

ezyang 에 2019년 04월 15일

물리적 NHWC 텐서가 순전히 스트라이드를 통해 발생할 수 있는 경우 메모리 형식 태그가 있을 때만 메모리 형식을 보존하도록 하지 않는 한 이것은 기술적으로 BC 깨는 것입니다. 제안이 현재 무엇을 제안하고 있는지 잘 모르겠습니다.) 이것이 실제로 실제로 누군가의 코드를 손상시키는지 확실하지 않습니다.

메모리 형식을 '고정'으로 만들 수 있다고 가정합니다. 메모리 형식 텐서에 대한 연산은 메모리 형식 텐서를 생성합니다. 그러면 BC 문제가 해결됩니다.

그러나 텐서의 메모리 형식이 다른 경우 이진(또는 더 많은 멤버) 작업의 동작을 정의해야 합니다.

VitalyFedyunin 에 2019년 04월 15일

@ezyang 오 방금 위의 답변에 오타가 있음을 발견했습니다. (죄송합니다. 그러나 원래의 예는 여전히 정확합니다.) 아래와 같이 다시 설명하겠습니다.

NCHW 텐서가 있습니다(물리적으로, 연속적).
그런 다음 NWHC(논리적으로)로 치환합니다.
contiguous() 호출이 뒤따르는 NHWC로 더 치환하고 싶습니다.
NHWC(물리적)로 사용합니다.

하지만 2단계 이후에 이미 NHWC 연속성을 얻었습니다. 그런 다음 3단계를 건너뛰고 4단계에서 직접 NHWC로 사용할 수 있습니다. 하지만 이것은 텐서의 물리적 순서가 전혀 변경되지 않기 때문에 확실히 옳지 않습니다.

uyongw 에 2019년 04월 15일

차단된 형식에는 완전히 다른 연산자 구현 집합이 필요합니다. 이러한 이유로 우리는 정의상 모든 기존 연산자와 친숙하고 동일하거나 더 나은 성능으로 작동하는 '메모리 형식'과 혼합하지 않는 것을 선호합니다.

예, 첫 번째 단계로 NHWC를 활성화할 수 있습니다. 그러나 실제로 차단된 형식이 완전히 다른 것이라고 생각하지 않습니다. 그것은 자연스럽게 표현될 수 있습니다(약간의 좋은 추상화로). 일반적인 형식 설명이 있는 경우 다른 사람들은 임의의 차단/보폭으로 새 형식을 등록할 수 있습니다.

더군다나 이미 지원을 차단했다면 기본이 되는 모든 것을 실행하기 위해 숨겨진 구성을 만드는 데 신경 쓰지 않아도 됩니다. 내부에 암시적 세계가 생성되고 두 세계 사이의 시작/끝이 문제가 될 수 있습니다.

어쨌든 차단된 형식에 대해 생각하기에는 너무 멀리 떨어져 있을 수 있습니다. 하지만 가능하면 디자인을 확장 가능하게 만드는 것이 더 낫다고 생각합니다.

uyongw 에 2019년 04월 15일

하지만 2단계 이후에 이미 NHWC 연속성을 얻었습니다. 그런 다음 3단계를 건너뛰고 4단계에서 직접 NHWC로 사용할 수 있습니다. 하지만 이것은 텐서의 물리적 순서가 전혀 변경되지 않기 때문에 확실히 옳지 않습니다.

알겠습니다. 이제 귀하의 예를 이해합니다. 실제로 2단계에서 멈추고 NCHW 텐서인 것처럼 사용할 수 있습니다. 이 경우 W를 C 등으로 부적절하게 해석하게 됩니다. 이것은 확실히 보폭 기반 구현의 단점입니다( @dzhulgakov , 아마도 이것을 제안에 추가해야 할 것입니다). 제안서에는 이 경우에 대한 몇 가지 조항이 있습니다.

위의 문제를 해결하기 위해 초기 제안은 텐서에서 수행된 마지막 to(memory_format) 호출을 기록하는 "소프트" 메모리 형식 태그를 텐서에 도입하는 것입니다. 운영자는 이 주석을 출력에 전파해야 합니다. 주석은 "소프트"이므로 불일치 주석에 대한 하드 오류가 발생하지 않고 프로파일링 모드에서 경고가 생성됩니다.

소프트 메모리 형식 태그를 사용하면 순열한 NCHW 텐서와 실제로 물리적으로 NHWC인 텐서를 구별할 수 있습니다. 그러나 현재 형식의 소프트 태그는 구속력이 없으므로 실제로 이 경우에 얼마나 유용한지 잘 모르겠습니다.

문제를 해결하는 또 다른 방법은 명명된 텐서를 사용하는 것입니다. 명명된 텐서를 사용하면 (논리적) 차원의 이름을 사용하여 텐서를 NCHW(가정 기본값)로 보고 있는지 아니면 다른 것으로 보고 있는지 파악할 수 있습니다.

그러나 실제로 차단된 형식이 완전히 다른 것이라고 생각하지 않습니다. 그것은 자연스럽게 표현될 수 있습니다(약간의 좋은 추상화로). 일반적인 형식 설명이 있는 경우 다른 사람들은 임의의 차단/보폭으로 새 형식을 등록할 수 있습니다.

여기에 주제에 대한 더 많은 설명이 있습니다: https://github.com/pytorch/pytorch/issues/16038#issuecomment -454490374

ezyang 에 2019년 04월 15일

@ezyang 답변 감사합니다. 예, 소프트 형식 태그가 도움이 될 수 있습니다. 문제는 차원 순서가 임의적일 수 있으므로 충분히 유연하지 않을 수 있다는 것입니다. 또한 자체적으로 계산할 수 없습니다. 명명된 텐서는 각 차원에 대한 의미론적 의미를 갖지만 지원하기 위해 더 많은 기능이 필요할 수 있습니다.

개인적으로 나는 이것이 보폭 순서(물리적)에서 NCHW 크기 순서(논리적)로의 맵을 도입하여 해결할 수 있다고 생각합니다. 위에서 제안한 것처럼 NCHW의 경우 현재 디자인과 거의 동일합니다. NHWC의 경우 sizes 는 여전히 NCHW이고 strides 는 (N, H, W, C) 순서입니다. 그리고 stride_index = (0, 2, 3, 1)을 사용하여 보폭의 차원 인덱스를 지정합니다.

또한 strides 및 stride_index 의 조합을 사용하여 모든 텐서 형식을 나타낼 수 있습니다. 이것은 다른 사람들이 새로운 데이터 형식을 등록할 수 있는 유연성을 제공할 수 있습니다.

uyongw 에 2019년 04월 16일

@ezyang

작업은 메모리 형식 동작을 유지합니다.
물리적 NHWC 텐서가 순전히 스트라이드를 통해 발생할 수 있는 경우 메모리 형식 태그가 있을 때만 메모리 형식을 보존하도록 하지 않는 한 이것은 기술적으로 BC 깨는 것입니다. 제안이 현재 무엇을 제안하고 있는지 잘 모르겠습니다.) 이것이 실제로 실제로 누군가의 코드를 손상시키는지 확실하지 않습니다.

산술 연산과 임계값이 TensorIterator로 이동했을 때 이는 기술적으로 BC 파괴였습니다(피연산자의 메모리 형식이 보존되지 않고 TensorIterator가 이를 보존하기 때문입니다). 현재 상태는 매우 일관성이 없습니다. 임계값은 레이아웃을 유지하지만, 다른 모든 단항 연산은 그렇지 않으며, torch.where는 그렇지 않습니다. 두 피연산자의 레이아웃이 동일한 경우 산술 연산은 레이아웃을 유지하지만 기본값은 "nchw" 또는 contiguous 텐서입니다 contiguous 미스매칭이 있을 경우 방송은 어떻게 되는지 잘 모르겠습니다.
또한 BC가 아닌 레이아웃을 유지하는 empty_like 대해 좋은 지적을 하고 있습니다. 아마도 제안서의 is_contiguous와 같은 레이아웃 인수가 필요할 것입니다.

x.is_contiguous(torch.memory_format.channels_first)

ngimel 에 2019년 04월 17일

@ezyang @ngimel

empty_like에는 한 가지 문제가 있습니다. 현재 정의된 의미는 모든 보폭 정보를 삭제한다는 것이므로 레이아웃을 유지하고 BC가 될 수 없습니다.
또한 BC가 아닌 레이아웃을 유지하는 empty_like 등에 대해 좋은 지적을 하고 있습니다.

우리가 물리적 질서를 표현하기 위해 보폭에 의존하지 않는다면, empty_like 는 BC를 깨뜨릴 필요가 없습니다. 텐서에는 3가지 차원 정보가 있습니다.

모양: 크기
논리 순서: 보폭으로 기록된 순서 정보(일반적으로 전치 또는 순열을 지원하는 데 사용됨)
물리적 순서: NCHW 또는 NHWC(제가 제안한 대로 stride_index로 처리할 수 있음).

현재 물리적 순서는 모양/크기와 동일합니다. 그래서 우리는 논리 순서를 보폭으로 떨어뜨립니다. 모양과 물리적 순서를 분리한다고 생각하면 논리 순서를 삭제할 수도 있지만 empty_like 대한 모양과 물리적 순서는 보존할 수 있습니다. 즉, size() 및 stride_index() 는 모두 보존되지만 stride() 는 재설정됩니다. 특히 NHWC 텐서의 empty_like 는 동일한 모양 정보가 지정된 NHWC 연속 텐서를 반환합니다.

uyongw 에 2019년 04월 17일

@uyongw empty_like 변경하는 것이 좋은 생각인지 잘 모르겠습니다. 지금 그 의미는 numpy의 empty_like 와 일치합니다.

현재 상태는 매우 일관성이 없습니다. 임계값은 레이아웃을 유지하지만, 다른 모든 단항 연산은 그렇지 않으며, torch.where는 그렇지 않습니다. 두 피연산자가 동일한 레이아웃을 갖고 있는 경우 산술 연산은 레이아웃을 유지하지만 기본값은 "nchw" 또는 인접하는 텐서입니다. 불일치가 있는 경우 현재 이해하고 있지만 방송은 어떻게 되는지 잘 모르겠습니다.

@ngimel , 예, 지금은 일관성이 없습니다. 메모리 형식을 표현하는 방법의 일부는 연산자를 일관된 상태로 만드는 것이라고 생각합니다.

zou3519 에 2019년 04월 17일

@zou3519 링크한 numpy의 empty_like에는 기본적으로 "프로토타입의 레이아웃과 최대한 가깝게 일치"하는 order 인수가 있습니다. 그것은 pytorch의 empty_like 가 현재 수행하는 작업이 아닙니다(프로토타입이 연속적이지 않은 경우에도 "nchw"- 연속 텐서를 반환함)

ngimel 에 2019년 04월 17일

아, 너무 빨리 읽었네요. 그 경우에 우리의 empty_like 일치 numpy를 갖는 것이 좋을 것이고 여기에서 메모리 레이아웃도 갖는 것이 좋을 것입니다(아마도?)

zou3519 에 2019년 04월 17일

@zou3519 네, 제가 말하려는 것은 현재 의미론( @ezyang 및 @ngimel이 언급한 것처럼 논리적 순서 삭제)을 유지하고 동시에 numpy의 기본값과 같은 물리적 레이아웃을 유지하는 것입니다. 따라서 NCHW 프로토타입의 경우 동작은 이전과 동일합니다. NHWC 프로토타입의 경우 동작은 여전히 호환됩니다. 즉, 현재 구현을 변경하지 않으면 새 텐서는 NCHW 연속 대신 NHWC 연속이 됩니다.

uyongw 에 2019년 04월 18일

두 가지 질문:

NHWC 텐서를 NCHW 텐서에 추가하면 어떻게 됩니까?
차원의 물리적 위치를 나타내는 정수 값을 반환하는 텐서에서 t.channel_dim()과 같은 메서드를 만들어 (B)의 단점을 해결하는 것은 어떻습니까? 이 접근 방식은 블록 형식과 같은 다른 형식을 네트워크 변경 없이 선택할 수 있도록 하는 데 필요할 수도 있습니다.

마지막 글머리 기호로 (B)의 단점을 해결하면 (B)가 나에게 더 나은 것 같습니다. 직관적으로 명확하고 논리적 오류를 감지하기 쉬워야 합니다. 기존의 모든 연산은 다른 인접 텐서처럼 보이기 때문에 텐서에서도 작동할 수 있습니다. 시맨틱(명명된 텐서 제안과 유사)을 이해할 수 있는 작업도 예상대로 수행됩니다.

mruberry 에 2019년 04월 19일

@zou3519 링크한 numpy의 empty_like에는 기본적으로 "프로토타입의 레이아웃과 최대한 가깝게 일치"하는 order 인수가 있습니다. 그것은 pytorch의 empty_like 가 현재 수행하는 작업이 아닙니다(프로토타입이 연속적이지 않은 경우에도 "nchw"- 연속 텐서를 반환함)

이러한 경우 형식을 유지할 계획입니다(메모리 형식 텐서의 경우).

NHWC 텐서를 NCHW 텐서에 추가하면 어떻게 됩니까?
메모리 형식 텐서를 사용한 작업은 메모리 형식 텐서를 반환합니다. 두 텐서가 모두 메모리 형식인 경우 출력 형식은 첫 번째 텐서에 의해 결정됩니다.

VitalyFedyunin 에 2019년 04월 19일

내가 추가할 두 가지:

이러한 경우 형식을 유지할 계획입니다(메모리 형식 텐서의 경우).

종종 운영자가 empty_like 호출한 다음 NCHW 연속이라고 가정하기 때문에 기존 사용을 감사해야 합니다. 그리고 제3자 코드를 어떻게 처리할지 모르겠습니다. BC를 보존하려면 numpy와 다른 기본값이 필요한 것 같습니다.

메모리 형식 텐서를 사용한 작업은 메모리 형식 텐서를 반환합니다. 두 텐서가 모두 메모리 형식인 경우 출력 형식은 첫 번째 텐서에 의해 결정됩니다.

또한 출력 형식이 무엇인지 정말 중요하다면 출력 텐서를 전달합니다.

gchanan 에 2019년 04월 19일

empty_like에 동의합니다. empty_like/zeros_like 등의 결과가 nchw-contiguous로 간주되는 경우가 꽤 있습니다(물리적으로 연속적이라고 말해야 합니다. 많은 경우 이미지 작업이 아님).
out kwarg가 있는 함수는 미분할 수 없기 때문에 출력 텐서를 전달하는 것은 대부분의 경우 옵션이 아닙니다.

ngimel 에 2019년 04월 19일

우리의 많은 문제는 예상되는 출력 레이아웃의 불일치에서 비롯됩니다. 한 번에 모든 문제를 해결할 수는 없지만 현재 상태를 잠그고(적어도 보폭에 대해서는) 하나씩 해결해 볼 수 있습니다. 여기 제안이 있습니다.

파이썬 API

새로운 torch.memory_format을 소개합니다.

torch_memory_format.any # default value
torch_memory_format.preserve
torch.memory_format.contiguous # what most of the functions now behave as default
torch.memory_format.nchw # requires 4D tensor, contiguous memory
torch.memory_format.nhwc # requires 4D tensor, restrided/permuted memory

텐서는 명시적 메모리 형식 변환이 필요합니다.

x = torch.zeros((10,3,32,32)) # NCHW
x.permute(0,2,3,1).is_contiguous(memory_format=torch.memory_format.nhwc) == False # because memory still layed out as NCHW

특정 형식으로 '태그'하려면:

y = x.to(memory_format=torch.memory_format.nhwc)
y.is_contiguous(memory_format=torch.memory_format.nhwc) == True # We got new tensor with proper memory layout
y.is_contiguous() == False # Required for back compatibility
y.stride() == (3072, 3, 1, 96)

이제 empty_like 및 유사에 대해:

z = torch.empty_like(y) 
z.is_contiguous() == True # For BC

실제로 다음과 같기 때문입니다.

z = torch.empty_like(y, memory_format=torch.memory_format.any )

형식을 유지하려면:

z = torch.empty_like(y, memory_format=torch_memory_format.preserve) 
z.is_contiguous() == False 
z.is_contiguous(memory_format=torch.memory_format.nhwc) == True

비슷하게:

z = torch.empty_like(y, memory_format=memory_format=torch.memory_format.nhwc) 
z.is_contiguous() == False 
z.is_contiguous(memory_format=torch.memory_format.nhwc) == True

즉, 각 함수 memory_format 기본값을 세계의 현재 상태로 천천히 정의하고 분류하고 미래에 변경할 방법을 염두에 둘 수 있습니다.

텐서를 지정하면 TensorOptions가 현재 무시됩니다(가장 좋은 경우 예외가 발생하는 것은 예를 들어 out 텐서 장치와 장치 옵션 불일치를 전달하는 것입니다).

메모리 형식은 가벼워야 하므로 순열이 손실될 것입니다.

x.zeros((10,3,32,32), memory_format=torch.memory_format.nhwc)
x = x.permute(0,1,3,2).permute(0,1,3,2)
x.is_contiguous(memory_format=torch.memory_format.nhwc) == False (even if strides are similar)

패딩이 확실하지 않은 경우 여기에서 도움을 주시면 감사하겠습니다.

그러나 적절한 형식으로 x.to(memory_format=torch.memory_format.nhwc) 'tag' 텐서를 만들고 자체를 반환할 수 있습니다.

다중 처리

메모리 형식 '태그'를 유지합니다.

블록 메모리 형식

위의 API는 차원/보폭/크기에 의존하지 않으므로 향후 동일한 API를 유지하면서 기능을 확장할 수 있습니다.

내부 API

연산자는 메모리 형식에 따라 분기할 수 있습니다.

if (self.memory_format(nhwc)) {
 // fast path
} else
{
 // classic implementation
}

memory_format을 TensorOptions로 하면 디스패치 수준에서 분기하는 것을 생각할 수 있습니다(디바이스, 레이아웃과 유사).

VitalyFedyunin 에 2019년 04월 19일

@VitalyFedyunin 의 제안에 대한 작은 피드백 - 여기에 4D 텐서가 필요하다고 생각합니다.

torch.memory_format.nchw # requires 4D tensor, contiguous memory
torch.memory_format.nhwc # requires 4D tensor, restrided/permuted memory

너무 제한적이며(2D 외에 1D 및 3D도 처리해야 하기 때문에) 원래 제안의 channels_first/channels_last 가 이 목적에 더 적합했습니다.

ngimel 에 2019년 04월 19일

동의합니다. 더 나은 이름 지정이 필요합니다. channels_first 는 일괄 처리가 먼저 진행된다는 점을 제외하고 거의 옳게 들립니다 =)

VitalyFedyunin 에 2019년 04월 19일

나는 당신의 최신 제안을 좋아합니다. .contiguous() 처리가 변경됩니까? .contiguous(memory_format=<...>)가 필요합니까? 그렇다면 많은 작업이 단순히 .contiguous()를 호출하지만 여전히 메모리를 부적절하게 포맷하고 있을 수 있습니다. 오늘날 많은 작업에서도 동일한 효과를 낼 수 있는 empty_like()로 출력을 할당합니다. 입력의 메모리 형식을 감지하고 올바른 연속적이고 empty_like 호출을 수행하도록 업데이트할 계획입니까?

mruberry 에 2019년 04월 20일

지금 당장은 .contiguous() 가 메모리 연속 텐서를 내림차순으로 보폭으로 반환할 것으로 기대하는 사용자(및 모든 라이브러리)입니다.

우리는 이 계약을 깰 수 없습니다. 그러나 좋은 소식은 memory_format 옵션을 지원하는 즉시 JIT가 클래식 형식 대신 .contiguous(memory_format=...) 를 호출하는 것이 더 효율적인 때를 이해할 수 있다는 것입니다.

VitalyFedyunin 에 2019년 04월 22일

👍1

@VitalyFedyunin 아래와 같은 작업은 허용되지 않는다고 가정합니까?

x.zeros(10,3,32,32)
# x is in nchw (default)
# x.size() is [10,3,32,32]
# x.stride() is [3*32*32, 32*32, 32,1]
x = x.permute(0,2,3,1)
# At this point 
# x.size() is [10,32,32,3], size is not in nchw order
# x.stride() is [3*32*32, 32,1,32*32]

# How can this be supported?
y = x.to(memory_format=torch.memory_format.nhwc)

또 다른 변형은 다음과 같습니다.

x.zeros(10,3,32,32)
# `x` is in nchw (default)
# x.size() is [10,3,32,32]
# x.stride() is [3*32*32, 32*32, 32,1]
x = x.permute(0,2,3,1)
x=x.contiguous()
# At this point 
# x.size() is [10,32,32,3], size is not in nchw order
# x.stride() is [32*32*3, 32*3,3,1]

# How can this be supported?
y = x.to(memory_format=torch.memory_format.nhwc)

raghuramank100 에 2019년 05월 03일

@raghuramank100 - 사용자가 처음에 .permute(0,2,3,1) 를 호출하는 이유는 무엇입니까? 이 제안의 모든 텐서는 의미론적 크기가 (n,c,h,w)이며, 이는 size(1)이 채널을 반환함을 의미합니다. 그것이 오늘날 PT의 표준 라이브러리가 가정하고 이 제안에서도 가정하는 것입니다. 따라서 .permute를 전혀 호출하지 않을 것입니다.

dzhulgakov 에 2019년 05월 03일

컨텍스트 관리자가 사용자가 관리자 범위 내에서 할당된 텐서의 메모리 형식을 특정 형식으로 재정의할 수 있도록 하는 데 유용할 수 있습니까?

with torch.memory_format(torch.memory_format.nhwc):
    # a will be allocated with the context managed memory format   
    a = torch.randn(...)

# b will be allocated matching some assumed default format
b = torch.randn(...)

mfuntowicz 에 2019년 05월 03일

memory_format의 제어를 느슨하게 하기 때문에 컨텍스트 관리자의 아이디어가 마음에 들지 않습니다.

예를 들어:

with torch.memory_format(torch.channels_last):
  x = torch.randn(10,3,32,32) # this one is NHWC
  y = torch.randn(10,10) @ this one is not

명시적 memory_format이 명확하게 하는 경우:

x = torch.randn(10,3,32,32).to(memory_format=torch.channels_last) # this one is NHWC
y = torch.randn(10,10).to(memory_format=torch.channels_last) # This is errors out as dim == 2

필요한 경우 다음을 허용하는 구문을 추가할 수 있습니다.

x = torch.randn(10,3,32,32, memory_format=torch.channels_last)

VitalyFedyunin 에 2019년 05월 03일

@raghuramank100 순열할 필요가 없습니다.

y = x.to(memory_format=torch.channels_last)

x에서와 같이 희미한 순서를 유지하면서 모든 더러운 작업을 수행합니다.

그래서:

x = torch.randn(10, 3, 32, 32)
nhwc = x.to(memory_format=torch.channels_last)
self.assertFalse(nhwc.is_contiguous())
self.assertTrue(nhwc.is_contiguous(memory_format=torch.channels_last))
self.assertEqual(nhwc, x)

그리고 이 형식으로 nhwc를 계속 처리할 수 있습니다.

nhwc[N][C][H][W]

VitalyFedyunin 에 2019년 05월 03일

@VitalyFedyunin 그것은 의미가 있습니다.

사용자의 관점에서 볼 때 메서드 이름(이대로 유지되는 경우)은 "to"가 이미 Tensor를 다른 장치로 전송하는 데 권장되는 방법이므로 오해의 소지가 있는 것 같습니다.

또한 C_ORDER 및 F_ORDER 배열을 변환하는 Numpy의 것과 같은 것은 어떻습니까?

numpy.asfortranarray()
numpy.ascontiguousarray()

다음과 같은 것을 쉽게 상상할 수 있습니다.

torch.randn(32, 3, 64, 64).to(device).as_nhwc()

mfuntowicz 에 2019년 05월 03일

👍1

@VitalyFedyunin : 다른 memory_format으로 변환하면 사용자가 수동으로 변경할 필요가 없다는 것을 이해합니다. 그러나 이 기능을 토치에서 사용할 수 있게 되면 위에서 설명한 순서대로 사용자가 함수를 호출하면 어떻게 될까요? 최소한 레이아웃 변환이 실패했다는 경고/오류 메시지가 있어야 합니다.

raghuramank100 에 2019년 05월 03일

@VitalyFedyunin : 다른 memory_format으로 변환하면 사용자가 수동으로 변경할 필요가 없다는 것을 이해합니다. 그러나 이 기능을 토치에서 사용할 수 있게 되면 위에서 설명한 순서대로 사용자가 함수를 호출하면 어떻게 될까요? 최소한 레이아웃 변환이 실패했다는 경고/오류 메시지가 있어야 합니다.

이것은 명명된 텐서를 구현할 때만 가능합니다. 지금 당장:

x.zeros(10,10,10,10)
x = x.permute(0,2,3,1)

내가 방금 nchw 또는 nhwc를 만들었는지 아무도 알 수 없습니다.

VitalyFedyunin 에 2019년 05월 03일

내가 원래 제안을 잘못 이해했을 수도 있지만 기록된 메모리 형식 태그가 이 상황을 명확하게 해야 하는 것 아닌가요?

ezyang 에 2019년 05월 06일

@VitalyFedyunin 이 API가 안정화되면 최종 사용자에게 이를 전달해야 합니다.

raghuramank100 에 2019년 05월 06일

@dzhulgakov @VitalyFedyunin #19975를 검토한 후 텐서에 기록된 메모리 형식 태그에 대한 몇 가지 새로운 우려가 있습니다. 내 기본적인 문제는 작업이 메모리 태그를 보존해야 하는지 여부를 어떻게 결정해야 합니까? 원래는 "대체 레이아웃 인식" 운영자만 이러한 영리함을 갖추어야 한다고 생각했습니다. 하지만 Vitaly의 패치를 보면 일부 핵심 오퍼레이터도 조정이 필요하다고 생각합니다. 예를 들어 x[0] ; x가 이전에 NHWC 텐서라면 이 작업을 수행한 후 HWC 텐서를 가져와야 합니다. 나는 Vitaly의 패치가 이것을 올바르게 처리하지 못한다고 확신하며, 이는 사용자에게 매우 혼란스러울 것입니다. 아마도 영향을 받는 유일한 연산자는 보폭을 처리하는 연산자(이 경우 너무 많지 않고 수동으로 감사할 수 있음)이지만 우리가 해야 할 일인 것 같습니다. 어떻게 생각하나요?

ezyang 에 2019년 05월 10일

잠깐, 텐서는 여전히 다음 순서로 인덱싱된 상태를 유지합니다. 0-dim N; 1차원 C; 2차원 H; 3rd-dim W. 따라서 x[0]은 0-dim C를 가진 텐서를 반환합니다. 1차원 H; 2nd-dim W. x가 channel_first 또는 channel_last 메모리 레이아웃인지 여부에 관계없이.

그렇지 않으면 memory_format이 의미가 없으며 텐서를 치환하기만 하면 됩니다.

VitalyFedyunin 에 2019년 05월 10일

내 요점은 메모리 형식 태그가 보존되지 않는다는 것입니다. 입력 텐서에 channels_last 태그가 지정된 경우 새 텐서는 any 태그가 지정됩니다.

ezyang 에 2019년 05월 10일

cc @zou3519 , 여기 레이아웃 전파 논리는 명명된 텐서 작업에서 명명된 차원 전파를 많이 생각나게 합니다.

ezyang 에 2019년 05월 10일

나는 여전히 이 제안을 따라잡고 있다. 그러나 @ezyang 은 차원별 플래그(또는 이름)를 전파하여 레이아웃 전파 논리를 추적할 수 있으며, 그러면 이름 규칙을 사용하여 명명된 텐서를 갖는 것과 같습니다.

zou3519 에 2019년 05월 13일

메모리 태그 로직과 명명된 텐서 로직을 정확하게 정렬할 수 있다면, 비록 처음에 두 개의 개별 구현 경로가 있더라도 깔끔할 것입니다.

ezyang 에 2019년 05월 14일

👍1

1단계

두 개의 텐서 함수 .is_contiguous 및 .contiguous (python 및 C++ API 모두)의 기능을 확장합니다.

참고: .to(memory_format) 기능에 대한 몇 가지 불만이 있었고 지원하지 않기로 결정했습니다.

.contiguous 이제 선택적 키워드 전용 인수인 memory_format 합니다. torch.contiguous_format 또는 torch.channels_last 있습니다.
- torch.contiguous_format 하면 기존 .contiguous() 동작이 유지됩니다.
- x.contiguous(memory_format=torch.channels_last) 호출하면 동일한 의미적 레이아웃(NCHW)을 유지하지만 메모리 할당 패턴이 다른 새 텐서를 반환합니다.
  x.contiguous(memory_format=torch.channels_last) 는 입력 텐서가 3d, 4d 또는 5d일 것으로 예상합니다. 그렇지 않으면 실패합니다.
.is_contiguous 이제 선택적 키워드 전용 인수인 memory_format 합니다. torch.contiguous_format 또는 torch.channels_last 있습니다.
- x.is_contiguous(memory_format=torch.contiguous_format) 는 x.is_contiguous() 와 동일한 기능을 유지하며 변경되지 않은 상태로 유지됩니다.
- x.is_contiguous(memory_format=torch.channels_last) 는 A) 입력 텐서가 메모리에서 연속적이고 B) NWHC(또는 3d,5d의 경우 유사) 형식으로 메모리에 할당된 경우 true를 반환합니다.

참고: 1단계가 끝날 때 x.is_contiguous(memory_format=torch.channels_last) 는 모든 호출에서 Tensor의 상태를 계산합니다. 이 기능은 나중에 업데이트될 예정입니다.

VitalyFedyunin 에 2019년 05월 14일

2 단계

특정 작업에 대한 메모리 형식 유지:

단항 요소별 연산자는 channel_last 메모리 형식을 유지합니다.

a = torch.randn(N,C,H,W)
b = a.contiguous(memory_format=torch.channels_last)
c = b.sin()
c.is_contiguous(memory_format=torch.channels_last) == True

이진 요소별 연산자( add , sub , mul , div )는 channels_last 메모리 형식을 유지합니다.

a = torch.randn(N,C,H,W)
b = a.contiguous(memory_format=torch.channels_last)
c = b * torch.randn(H,W)
c.is_contiguous(memory_format=torch.channels_last) == True

크기, 보폭 및 흐림에 대한 모든 작업은 메모리 형식을 재설정합니다.

a = torch.randn(N,C,H,W)
b = a.contiguous(memory_format=torch.channels_last)
c = b.permute(0,2,3,1).permute(0,3,1,2)
c.is_contiguous(memory_format=torch.channels_last) == False

미정

출력이 읽을 수 있는 'channels_last'인 경우 모양 변경(및 유사) 작업의 결과

import torch
a = torch.randn(N,C,H,W)
b = a.contiguous(memory_format=torch.channels_last)
c = b.reshape(N,C,-1)
c.is_contiguous(memory_format=torch.channels_last) # ?

참고: 현재 memory_format이 보존되지 않았습니다.

NHWC + NCHW 작업의 결과입니다. NHWC인가요?
참고: 현재 NHWC + NCHW -> NHWC 및 NCHW + NHWC -> NHWC

VitalyFedyunin 에 2019년 05월 14일

cat/split과 같은 작업은 어떻습니까? 메모리 형식을 유지하는 데 유용합니다.

raghuramank100 에 2019년 05월 16일

@ezyang - 인덱싱과 관련하여 어딘가에서 멈춰야 한다고 생각합니다. 다른 메모리 레이아웃은 완전히 투명하지 않으며 일부 작업에서는 이를 무시하도록 허용해야 합니다. x[0] 는 x[0].unsqueeze(0) 포함하여 태그를 지울 수 있어야 한다고 주장합니다.

Raghu가 언급했듯이 cat/split은 매우 일반적인 사용법이지만 가능하면 태그를 보존해야 합니다. 일반적인 경험 법칙은 운영이 순위를 변경하거나 축을 이상하게 재정렬하지 않는 한 태그를 유지해야 한다는 것입니다. 순위가 변경되면 모든 베팅이 해제됩니다.

dzhulgakov 에 2019년 05월 22일

어떤 경우에는 태그를 잃게 된다는 데 동의합니다. 하지만 x[0] 대해서는 동의하지 않습니다. 나에게 그것은 NCHW 에서 CHW 로 가는 매우 일반적인 방법인 것 같습니다.

ezyang 에 2019년 05월 22일

텐서가 channel_last '태그'를 전달(또는 포함하지 않음)하는 것이 얼마나 혼란스러운지에 대해 몇 차례 대화를 나눈 후 우리는 bc-브레이킹 변경을 도입하고 텐서를 channel_last 형식으로 자동 승격하는 위험을 감수하기로 결정했습니다.

API에 대한 의미:

N,1,H,[W,[D]]와 같은 스트라이드가 있는 모든 3d,4d,5d 텐서는 자동으로 channel_last 메모리 형식을 얻습니다.

작동하도록 하기 위해 channel_last 텐서를 출력하는 channel_last 텐서의 연산자가 인접한 텐서의 연산자와 최소한 비슷한 성능을 갖도록 보장하기 위해 특별한 예방 조치를 취할 것입니다.

최악의 시나리오의 경우:
1) 사용자는 출력에서 .contiguous()를 호출할 수 있습니다.
2) 우리는 이 동작을 변경하는 것이 거의 사소한 방식으로 자동 승격 코드를 작성할 것입니다.

이러한 자동 프로모션의 부작용은 다음과 같습니다.

import torch
x = torch.randn(10,16,16,3).permute(0,3,1,2) 
x.is_contiguous(memory_format=torch.channels_last) == True

다른 한편으로 (가벼운 수정 후) 경우를 해결할 수 있습니다.

import torch
x = torch.randn(10,3,16,16).contiguous(memory_format=torch.channels_last)
x = x[0].unsqueeze(0)
x.is_contiguous(memory_format=torch.channels_last) == True

VitalyFedyunin 에 2019년 06월 11일

@ezyang 의 요청에 따라 slack 변환에서

나탈리아 기멜샤인 [2:19 PM]
그래서 나는 태그의 개념이 없을 것이라고 생각합니다.

import torch
#batch = 10, channels = 4, spatial dimensions = 16
x = torch.randn(10,16,16,4).permute(0,3,1,2)
x.is_contiguous(memory_format=torch.channels_last) == True
y = torch.randn(10,16,16,2).permute(0,3,1,2)
x1,x2 = x.chunk(2, dim=1) #chunk along channels dimension, no longer contiguous
x1.is_contiguous(memory_format=torch.channels_last) == False #right? So, if a tensor like this comes into e.g. convolution, what am I supposed to do with it? Did it want to be NHWC? Did it want to be nchw?
z=y+x1 #y is channels_last, x1 is something, what is the z layout?```

비탈리 페두닌 [오전 8시 23분]
z는 channel_last가 될 것입니다.

비탈리 페두닌 [오전 8시 25분]
x1이 제안된 변형에서 channel_last가 아닌 경우(청크 기능을 변경하여 뷰를 반환하지 않는 한), 컨볼루션은 이를 연속(channel_first) 형식으로 변환하고 연속도 반환합니다.

비탈리 페두닌 [오전 9:12]
@ngimel 피드백 주셔서 감사합니다. 보기와 같은 작업이 관련된 대부분의 경우를 다루기 위해 보다 의미 있는

나탈리아 기멜샤인 [오전 9시 36분]
스레드에 답변:
그래서 문제인 것 같죠? 채널 차원에서 청크하는 것은 예를 들어 시작과 같은 네트워크에서 비교적 일반적인 것입니다. 따라서 텐서가 청크된 채널 첫 번째 텐서인 경우 회선 출력은 채널 우선(직관적인 동작이며 사용자가 원하는 것일 수 있음)이 되고, 텐서가 청크된 채널 마지막인 경우 회선 출력은 다시 한 번 채널 첫 번째가 될까요?

나탈리아 기멜샤인 [오전 9:39]
스레드에 답변:
그러나 비 교환 덧셈 동작과 y 가 첫 번째 인수이고 채널이 마지막이기 때문입니다. 맞습니까? x1+y 의 결과는 무엇입니까? 어딘가에 이진 연산에 대한 레이아웃 전파 규칙이 있습니까?

비탈리 페두닌 [오전 10:44]
1) 네, 대안 제안으로 해결할 문제입니다. 나는 지금 몇 가지 테스트를 하고 있고 이번 주에 기록할 것입니다(하루나 이틀 후에).
2) x1+y - 또한 channel_last를 생성해야 합니다. 그렇지 않으면 혼란스럽습니다. 예, 레이아웃 전파 규칙이 기록됩니다.

ngimel 에 2019년 06월 19일

우리가 이 대면에 대해 이야기할 때 @VitalyFedyunin 에게 관찰한 내용은 (하지만 어디에도 이것을 적어두는 것을 기억하지 못했다고 생각합니다) 컨볼루션에는 어느 정도의 자유가 있다는 것입니다. 메모리 레이아웃이 효율적으로 구현하는 방법을 알고 있는 어떤 것과도 일치하지 않는 인수, 어떤 레이아웃에 연결해야 합니까? BC 이유로 채널을 먼저 연결해야 하지만 여기서 임의의 결정을 내렸습니다. 아마도 채널에 마지막으로 연결할 수도 있을 것입니다. 기본값이 무엇인지 알려주는 일종의 스레드 로컬 토글이 있어야 할까요?

그러나 여기에는 많은 세부 사항이 있는 것 같으며 결국 잘 될지 모르겠습니다.

ezyang 에 2019년 06월 19일

따라서 컨볼루션의 흐릿함(및 기타 레이아웃 인식 연산자, 예를 들어 최근에 본 업샘플링은 입력에서 .contiguous()을 호출하여 시작합니다. 그래서 그것이 의미하는 바가 무엇입니까?)이 주된 이유였습니다. 태그를 소개하기 위해 iirc.

ngimel 에 2019년 06월 19일

네, 그래서 태그 디자인을 다시 열어도 괜찮습니다. 하지만 우리는
이러한 태그를 전파하는 방법의 문제를 심각하게 해결해야 합니다.
레이아웃을 잃어도 (청킹의 경우와 같이
채널). 나는 "현재 레이아웃"을 만드는 것을 훨씬 더 좋아합니다.
데이터 종속성을 만드는 것보다 일종의 컨텍스트 관리자입니다.

2019-06-19 12:43:45 -0700의 ngimel 메시지에서 발췌:

따라서 컨볼루션의 흐릿함(및 기타 레이아웃 인식 연산자, 예를 들어 최근에 본 업샘플링은 입력에서 .contiguous()을 호출하여 시작합니다. 그래서 그것이 의미하는 바가 무엇입니까?)이 주된 이유였습니다. 태그를 소개하기 위해 iirc.

ezyang 에 2019년 06월 20일

apaszke 에 2019년 06월 27일

👍2

레이아웃 옵션이 고려되었지만(부록 확인) 많은 코드 중복이 발생하고 텐서를 즉시 다른 memory_format으로 자동 변환하는 것을 허용하지 않습니다.

결국 memory_format은 stride 텐서를 사용하고 완전히 다른 클래스가 아니라 strided 텐서의 속성인 최적화된 커널과 출력을 쉽게 선택하는 방법입니다.

VitalyFedyunin 에 2019년 06월 28일

어떤 의미에서 희소 레이아웃은 대부분이 0인 배열에 대해 최적화된 커널을 쉽게 선택하는 방법이기도 합니다.

apaszke 에 2019년 06월 29일

이것은 순진한 질문일 수 있지만, PyTorch가 이 API를 고려하는 것과 사용 가능한 경우 기본 CuDNN 커널을 직접 호출하는 작업 자체에서 NHWC를 사용하는 옵션을 노출하는 이유는 무엇입니까?

일반적인 사용 사례(conv 및 LM 아키텍처와 풀링과 같은 이미지 작업 혼합)의 경우 이것이 쉬운 솔루션인 것 같습니다. 개발자로서 내가 원하는 것은 Conv2d(..., nhwc=True) . 이게 말이 안 되는 이유가 있나요?

rewonc 에 2019년 09월 20일

👍1

@rewonc 우리는 유사한 접근 방식(

이 접근 방식은 커널이 NHWC 커널을 적용하기 위해 연속적인 텐서의 재스트라이딩을 수행해야 합니다.
다음 연산자는 nhwc=True 옵션이 없는 한 입력을 다시 재정의해야 합니다(연속적으로).
네트워크를 통해 NHWC를 사용하려면 모든 단일 운영자에게 nhwc=True 옵션이 필요합니다.

추신. CudNN Ex 함수가 걱정된다면 cudnn_batch_norm_nhwc 및 유사한 연산자를 노출하려고 합니다.

VitalyFedyunin 에 2019년 09월 20일

👍1

안녕하세요 @VitalyFedyunin님 , 우리는 명명된 텐서가 PyTorch 1.3에서 지원되는 것을 보았습니다. NHWC(또는 차단된) 형식 지원에 대한 문제를 해결(또는 부분적으로 해결할 수 있음)할 수 있습니까? 명명된 텐서를 기반으로 NHWC 상태로 나아갈 계획이 있습니까?

uyongw 에 2019년 10월 23일

우리는 채널의 마지막 지원을 계속 진행하고 있으며, 이번 주에 로드맵을 여기와 slack 채널에 게시할 예정입니다. (모든 연산자를 다시 작성해야 하므로) 차단된 형식을 곧 추가하는 것을 고려하지 않습니다.

VitalyFedyunin 에 2019년 10월 23일

감사 해요. 잘 될거야!

uyongw 에 2019년 10월 23일

https://github.com/pytorch/pytorch/issues/28619 내부의 태킹 작업 및 진행 상황

VitalyFedyunin 에 2019년 10월 25일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Pytorch: [RFC] 메모리 형식(일명 레이아웃이라고도 함) 지원

문제 설명

영향을 받는 운영자

API 및 동작 변경 사항

스트라이드 구현

연산자 구현

요소별 연산

성능 도구

Autograd 처리

JIT에서의 표현

Beyond: 차단된 레이아웃

명명된 텐서 관계

선행 기술

부록: 고려되는 기타 옵션

가장 유용한 댓글

모든 68 댓글

1단계

2 단계

관련 문제