CPU L1캐시가 한 32KB다 하면
int 4byte니까 8K개 정도가 한계잖아요
그러면 배열 연산할때 프로그래머가 8K개씩 일부러 쪼개서 캐시에 기분좋게 올리라고 도와주면
연산 속도가 유의미하게 좋아지나요?
아니면 OS가 알아서 해줘서 유저가 고려하는건 뻘짓인가요?
CPU L1캐시가 한 32KB다 하면
int 4byte니까 8K개 정도가 한계잖아요
그러면 배열 연산할때 프로그래머가 8K개씩 일부러 쪼개서 캐시에 기분좋게 올리라고 도와주면
연산 속도가 유의미하게 좋아지나요?
아니면 OS가 알아서 해줘서 유저가 고려하는건 뻘짓인가요?
OS 가 알아서 해주는건 더 큰 가상메모리의 페이징 단계예요.
캐시는 돈 아닌가여?
사용자가 직접 L1, L2, L3 캐시를 컨트롤할수 있는건 SIMD 계열 명령을 쓸 때죠.
intrinsic 형태로든요.
산화머니
오케이캐시
cache line 이라고 해서 64 ~ 128 byte 정도로 데이타를 잘라서 관리해 주는건 도움이 됩니다.
128bit SIMD 최적화를 돕기위해 128bit 자료형으로 선언하는 경우도 있긴 하지만, 어지간해선 다른데서 stall 이 발생하거나, 장애수준의 복잡한 표현이되느니 그냥 짜는게 좋아요.
페이징 단위 캐싱은 신경쓴다고 되는 레베루인지는 잘 모르게씀 캐시라이닝이랑 로컬리티만 좀 고려해서 하면 뭐..
1차캐시는대부분명령어캐시
멀티스레딩을생각한다면데이터의시작주소와크기를캐시라인크기에정렬