안녕하세요 !! 지난번 포스팅을 작성하면서 NEON을 분명 코드적으로 끄고 또 빌드할때나 cmake로 실행할때
[분석/검증-3] BitNet.cpp ARM 커널 재작성 : 스칼라 폴백구현을 통한 최종 검증
[분석/검증-3] BitNet.cpp ARM 커널 재작성 : 스칼라 폴백구현을 통한 최종 검증
1. 개요 및 이전 상황 요약https://uno-kim.tistory.com/458 [분석/검증-2] BitNet.cpp 텐서 연산 붕괴 현상 분석 : ARM 아키텍처 점곱 가속기의 하드웨어 결함 교본 테스트의 목적은 Exynos 1380 프로세서가 지원하
uno-kim.tistory.com
분명 NEON을 사용하지 않는다고 명시를 했는데도 실행만 했다면 NEON =1 이 켜진상태로 동작했다고 로그가 나타났었습니다.ㅠ
그 원인을 또 찾아보는 과정을 포스팅했습니다.
이번엔 freedom... 하는게 아니라 adooadoo 무한반복하면서 이젠 다 박살이 났습니다.
그런데 여기서 이상한점을 포착했습니다. 분명 NEON을 끈다고 별짓다했는데도 여기 시스템 인포에서
system_info: n_threads = 1 (n_threads_batch = 1) / 8 | AVX = 0 | AVX_VNNI = 0 | AVX2 = 0 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | AVX512_BF16 = 0 | FMA = 0 |NEON = 1 | SVE = 0 | ARM_FMA = 1 | F16C = 0 | FP16_VA = 0 | RISCV_VECT = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 0 | SSSE3 = 0 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 0 |
NEON이 1이었습니다... 왤까 하고 다시 깃허브 소스를 찾아봤더니 충격적이게도 llama.cpp 코드에서는 저희가 넘기고 썡쑈한 로직을 가져다 쓴게아니라 아래처럼...
그저 __ARM_ARCH면 NEON이 있다고 판단하래~ 하고 받아오는 값이었습니다...!!!
그러니 우리가 끄고 막 쌩쑈를 해도 계속 저기 로그에선 NEON = 1이렇게 나타나던것이었습니다 ㅠㅠㅠ
이걸 수정하게 된다면 저는 세계적인 라이브러리인 llama.cpp의 컨튜리 뷰터가 될 것같아서 설렙니다!
댓글