Hacker News 의견

• 대부분의 소프트웨어는 최적화되지 않아 성능 향상 여지가 많음

  • 알고리즘 선택이 가장 중요함
  • 커널 호출과 같은 무거운 작업을 줄일 수 있는지 확인 필요
  • 벡터화를 통해 성능 향상 가능
  • 캐시 효율성을 최적화할 수 있는지 확인 필요
  • 하드웨어에 특화된 최적화 가능성 검토 필요

• BLIS 레포지토리에 참조된 논문들은 이 주제를 이해하는 데 권위 있는 자료임

  • 최적화된 BLAS가 성능이 좋지 않다고 생각하는 이유를 이해하지 못함
  • numpy 대신 AMD의 BLAS를 사용해야 함
  • BLIS는 OpenBLAS보다 병렬화가 더 잘 되어 있음

• SIMD 명령어는 마이크로 커널 벡터화에 필요하지 않음

  • 적절한 블록 크기를 사용하면 BLIS의 순수 C 마이크로 커널이 손으로 최적화된 구현의 80% 이상의 성능을 발휘함

• 대부분의 코딩 패턴은 하드웨어에 완전히 특화되지 않아 많은 성능을 놓치고 있음

  • "There's plenty of room at the top"이라는 CS 클래식 논문을 참조할 만함

• 벤치마크를 쉽게 반복할 수 있게 한 점이 칭찬받을 만함

  • 16코어 Xeon CPU에서 matmul.c가 gcc -O3로 컴파일 시 1.41초, clang -O2로 컴파일 시 1.47초, NumPy는 1.07초 걸림
  • avx512 커널이 더 빠를 것이라고 믿음
  • omp 대신 pthreads를 사용해 스레드 풀을 명시적으로 관리하면 오버헤드를 줄일 수 있음

• numpy의 구현이 실제로 멀티스레딩을 사용하는지 의문임

• OpenBLAS보다 성능이 좋은 이유가 궁금함

  • 캐싱 등 세부 사항을 다루고 있음
  • 특정 프로세서에 더 최적화된 것인지 궁금함

• 한쪽은 Python, 다른 쪽은 C로 비교하는 것은 공정하지 않음

  • 둘 다 C로 작성하여 비교하는 것이 더 나음

• 마스크 생성의 비효율성이 신경 쓰임

  • 더 효율적인 방법으로 글로벌 상수 배열을 생성하거나 상수 벡터와 비교하는 방법이 있음
  • 하지만 이는 사소한 문제이며, 실제로는 큰 차이가 없을 것임

• 행렬 곱셈 자체를 멀티스레딩하는 것의 실용성에 의문을 가짐

  • 멀티스레딩은 행렬 곱셈을 사용하는 알고리즘에 더 유용할 것임

• jart의 tinyBLAS에 대한 언급

  • 관련 링크 제공