ImageMagick을 사용하여 대형 TIFF 이미지를 처리하고 있는데 제한된 리소스 환경(Alibaba의 Function Compute, AWS Lambda와 거의 동일)에서 처리가 이루어지기 때문에 메모리 문제가 발생합니다. 프로세스에 메모리가 부족할 때도 있고, 임시 디스크 공간이 부족할 때도 있습니다.
나는 현재 ImageMagick 바이너리의 64비트 버전을 사용하고 있다고 생각합니다 convert. 32비트에서 ImageMagick 바이너리를 사용자 정의 컴파일하는 경우 이미지 처리가 메모리의 절반을 사용할 수 있습니까?
나는 대답이 '아니요'라고 생각하지만 단지 다시 확인하고 싶었습니다. 내 생각에는 convert메모리에 로드된 바이너리의 크기가 절반이고 실제 이미지 처리는 64비트 버전의 convert.
답변1
64비트 프로그램과 32비트 프로그램의 차이는 일반적으로 프로그램이 직접 주소를 지정할 수 있는 메모리 양에만 영향을 미칩니다. 프로그램 자체는 프로그램 내의 변수 크기보다 더 많은 메모리 공간을 차지하지 않을 수 있습니다. IE: 32비트 바이너리의 C 프로그램에서 int의 최대값은 약 20억입니다. 64비트 바이너리의 int의 최대값은 9,223,372,036,854,780,000입니다. 이제 64비트 프로그램은 더 큰 메모리 공간에서 데이터를 읽거나 처리할 수 있지만 프로그램 자체는 더 이상 메모리를 사용하지 않습니다.
짧은 대답: 대용량 데이터 파일로 작업하는 경우 32비트 바이너리는 도움이 되지 않습니다.
답변2
64비트와 32비트는 런타임 메모리 사용량을 어느 정도 변경합니다.바늘. 에서는 amd64an int(기본 정수 유형)이 여전히 32비트이므로 변경되지 않습니다. 그러나 많은 수의 포인터 데이터 구조(예: 트리 또는 연결 목록)를 사용하는 프로그램이나 포인터를 통해 모든 변수에 액세스하는 고급 언어 해석기가 영향을 받을 수 있습니다. 128비트 구조를 가리키기 위해 64비트 포인터를 사용하면 50%의 오버헤드가 발생하는 반면, 32비트 포인터를 사용하면 25%만 발생합니다.
실제로 포인터 크기 때문에 64비트 시스템에서 32비트 응용 프로그램을 사용하기 위한 ABI 사양이 있지만 amd64그다지 주목을 받지 못하는 것 같습니다. 바라보다x32 ABI위키피디아에서.
ImageMagick은 이미지 데이터(주로 숫자 배열)를 다루기 때문에 아마도 큰 영향을 받지 않을 것입니다.