Zstd: Zstd 다중 스레드 출력은 스레드 수에 따라 달라질 수 있습니다.

다중 스레드 zstd 의 결과가 스레드의 nb에 의존하지 않는다고 말하는 것은 지름길입니다.

실제로 지원되는 기능은 _streaming_ multithreaded zstd 의 결과가 nb개의 스레드에 의존하지 않는다는 것입니다.
(그리고 이것이 zstd CLI에서 사용하는 것입니다).

이 정의를 통해 다른 잠재적인 수정 사항을 고려할 수 있습니다.
nbWorkers >= 1 일 때 ZSTD_e_end 대한 원패스 바로 가기를 사용하지 마십시오.
이 문제를 유발하는 것은 원패스 모드에 대한 위임이기 때문입니다.

이것은 단일 패스 MT 압축기를 적용하는 것보다 덜 방해가 될 수 있습니다.
이 보증을 제공하도록 설계되지 않았습니다.

또 다른 (잠재적으로 긍정적인) 부작용은 스트리밍 멀티스레드 압축이 _항상_ 비차단임을 보장한다는 것입니다. (차단) 단일 패스 모드에 더 이상 위임하지 않기 때문입니다.
_edit_ : ZSTD_e_flush 및 ZSTD_e_end 지시문을 수신하면 MT API 계약이 최소 순방향 진행에서 최대 진행.

또 다른 (잠재적으로 긍정적인) 부작용은 스트리밍 멀티스레드 압축이 더 이상 차단 모드에 위임되지 않기 때문에 항상 비차단임을 보장한다는 것입니다.

나는 한때 다중 스레드 압축에서 항상 차단되는 ZSTD_compressStream3() 함수를 추가하는 것을 제안하고 싶었습니다.

발신자가 계속해서 non-blocking 진행 상황을 확인하면 매우 불편 합니다.

편집 : 방금 찾았습니다. 진행 상황을 확인하는 것이 그다지 불편하지 않습니다.

do {
    zstd_ret = ZSTD_compressStream2(self->cctx, &out, &in, ZSTD_e_continue);
} while (out.pos != out.size && in.pos != in.size && !ZSTD_isError(zstd_ret));

그러나 항상 ZSTD_compressStream3() 차단하는 것이 더 낫습니다. 조금 더 빠를 수 있습니다. IMO 많은 프로그래머 사용자는 압축 진행률을 얻을 필요가 없습니다.

이것은 단일 패스 MT 압축기를 적용하는 것보다 덜 방해가 될 수 있습니다.
이 보증을 제공하도록 설계되지 않았습니다.

네, 그게 더 쉬울 겁니다. 싱글 패스 MT 압축기의 모든 작업을 한 번에 시작해야 한다는 사실을 잊고 있었습니다.

저는 한때 다중 스레드 압축에서 항상 차단되는 ZSTD_compressStream3() 함수를 추가하는 것을 제안하고 싶었습니다.

일반적으로 사람들이 스트리밍 압축 루프를 작성하는 방식은 최대한 앞으로 진행하지 않는 것이 크게 불편하지 않아야 합니다. 이와 같은 것을 추가한다면 새로운 API가 필요하지 않을 것입니다. 아마도 그것을 제어하기 위해 압축 매개변수를 추가해야 할 것입니다. 그러나 현재로서는 크게 필요하지 않습니다.