Hacker News 의견

• 40배 빠른 삼각법: std::sin 같은 표준 라이브러리 함수를 3줄의 코드로 가속화할 수 있음

  • 확장을 몇 개의 항으로 제한하여 sin(x)를 근사할 수 있음
  • 계산 비용은 줄어들지만 정확도도 감소함
  • 정확도 감소는 과소평가임. [-2, 2] 범위를 벗어난 입력에 대해 매우 부정확함
  • 단일 사인파 구간도 처리할 수 없으며 반복적인 특성도 다루지 못함. 쓸모없는 "최적화"임

• 마이크로컨트롤러에서의 경험 공유

  • 임베디드 시스템에서 작업 중이며, 힙은 약 256 KiB, 가장 큰 스택은 4 KiB임
  • 현대적인 C++를 주로 사용하지만 모든 트릭이 모든 상황에 적합하지 않음
  • CTRE는 스택 오버플로우를 피하는 한 괜찮음. HTTP 프록시 구성의 문자열을 검증하려고 시도했으나 스택 오버플로우로 인해 시스템이 충돌함
  • JSON을 내부적으로 거의 사용하지 않고 자체 BSON 라이브러리를 작성함. 메모리 할당이나 단편화를 걱정할 필요가 없음
  • newlib 대신 picolibc를 사용하고 C/C++ 표준 라이브러리 로케일 코드를 제거함. 프로그램 크기를 줄임

• Abseil의 선택에 대한 의견

  • 처음 등장했을 때 큰 이슈였지만, 이제는 약점을 개선한 여러 대안이 존재함
  • 최근 몇 년 동안 Abseil에 대한 불만이 증가함. Google에서 핵심 라이브러리 유지 관리자의 이탈이 있었음

• C++에서 성능을 위한 왜곡에 대한 비판

  • CTRE가 좋은 결과를 준다는 것에 놀람. 더 깊이 파고들 필요가 있음
  • OpenMP 및 TBB 스레드풀 벤치마크를 조사하고 Boost::ASIO 스레드풀을 추가할 수 있는지 확인하고 싶음

• FPGA와 GPU 코딩의 차이점 및 고급 합성, Verilog, VHDL에 대한 요청

  • 이 주제에 대한 우선 요청을 받고 싶음

• 비정규화된 부동소수점에 대한 새로운 정보

  • GPU에서 행렬을 곱할 때 가끔 궁금해함

• Google Benchmark 게시물에 대한 긍정적인 피드백

  • 성능 벤치마킹에 대한 집중이 좋음. 저장소가 잘 구성되어 있음

• "덜 느린 C, C++, 어셈블리 코드"에 대한 기대

  • C 코드도 포함될 줄 알았으나 .cpp와 .S만 있음
  • less_slow.cpp가 많은 C++ 특성을 사용함. "C"를 목록에서 제거하거나 수정이 필요함