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は画像データ（主に数値配列）を扱うため、おそらく大きな影響を受けません。