Hi, Tim. Thank you for bring such a cool quantization tool to the community. However, I met a issue when trying to compile bnb from source code on PPC64LE CPUs of my school.
The errors regarding x86_intrinsics which can be disabled via the flag (-DNO_WARN_X86_INTRINSICS) used, are there for a reason unfortunately, as the intrinsics which result in errors later on are not available in the GCC/G++ build on ppc64le CPUs.
The warning refers to a comment in the header file, which reads as follows:
#ifndef NO_WARN_X86_INTRINSICS
/* This header is distributed to simplify porting x86_64 code that
makes explicit use of Intel intrinsics to powerpc64le.
It is the user's responsibility to determine if the results are
acceptable and make additional changes as necessary.
Note that much code that uses Intel intrinsics can be rewritten in
standard C or GNU C extensions, which are more portable and better
optimized across multiple targets.
In the specific case of X86 MMX (__m64) intrinsics, the PowerPC
target does not support a native __vector_size__ (8) type. Instead
we typedef __m64 to a 64-bit unsigned long long, which is natively
supported in 64-bit mode. This works well for the _si64 and some
_pi32 operations, but starts to generate long sequences for _pi16
and _pi8 operations. For those cases it better (faster and
smaller code) to transfer __m64 data to the PowerPC vector 128-bit
unit, perform the operation, and then transfer the result back to
the __m64 type. This implies that the direct register move
instructions, introduced with power8, are available for efficient
implementation of these transfers.
Most MMX intrinsic operations can be performed efficiently as
C language 64-bit scalar operation or optimized to use the newer
128-bit SSE/Altivec operations. We recomend this for new
applications. */
#error "Please read comment above. Use -DNO_WARN_X86_INTRINSICS to disable this error."
#endif
The bitsandbytes code, inside include/SIMD.h and include/Algo-Direct2.h use these intrinsics, which are not portable across CPU architectures. These are included by BinSearch.h, which is included by common.h, cpu_ops.cpp and ops.cu. without any CPU architecture guarding.
The PPC64LE version(s) of GCC etc do attempt to automatically convert these intrinsics to the PPC64LE equivalents when DNO_WARN_X86_INTRINSICS is set, but unfortunately this does not succeed for this code, and it will only work on x86_64 CPUs.
For this to build on PPC64LE, this will require changes to the source code, to either replace these intrinsics with portable versions which are PPC64LE compatible, or guard them out with macros so they can be disabled, and a PPC64LE compatible alternative put in place.
Hi, Tim. Thank you for bring such a cool quantization tool to the community. However, I met a issue when trying to compile bnb from source code on PPC64LE CPUs of my school.
The errors regarding x86_intrinsics which can be disabled via the flag (-DNO_WARN_X86_INTRINSICS) used, are there for a reason unfortunately, as the intrinsics which result in errors later on are not available in the GCC/G++ build on ppc64le CPUs.
The warning refers to a comment in the header file, which reads as follows:
The bitsandbytes code, inside include/SIMD.h and include/Algo-Direct2.h use these intrinsics, which are not portable across CPU architectures. These are included by BinSearch.h, which is included by common.h, cpu_ops.cpp and ops.cu. without any CPU architecture guarding.
The PPC64LE version(s) of GCC etc do attempt to automatically convert these intrinsics to the PPC64LE equivalents when DNO_WARN_X86_INTRINSICS is set, but unfortunately this does not succeed for this code, and it will only work on x86_64 CPUs.
For this to build on PPC64LE, this will require changes to the source code, to either replace these intrinsics with portable versions which are PPC64LE compatible, or guard them out with macros so they can be disabled, and a PPC64LE compatible alternative put in place.