1이라고 함 ㅇㅅㅇ
---- 아래는 수정 내용 ---
내가 참조한 자료들
1. https://docs.oracle.com/cd/E29584_01/webhelp/PerfTuning/src/cperf_recommended_threading_strategies_and_os_platform.html#:~:text=The%20size%20of%20the%20thread,good%20performance%20in%20most%20cases.
ㅡ wounded healer
하이퍼쓰레딩 오열 ㅇㅅㅇ - dc App
ㅠㅅㅠ ... 힝힝.. 근데 그거 혹시 하드웨어쪽 개념? 난 그거 잘 몰라ㅛㅓ ㅡ wounded healer
너가 코어당 스레드라고 했으니 하드웨어 개념말한거 아님 ㅇㅅㅇ? - dc App
아. ㅎㅎ ㄴㄴ 난 소프트웨어에서 생성해주는 쓰레드 얘기였음. 예를 들면 쓰레드풀 크기 설정할 때 잡아주는 쓰래드 개수 같은거 ㅇㅅㅇ ㅡ wounded healer
IBM Power제품이 1코어당 4쓰레드였나 의문의 1패 - dc App
그거도 하이퍼쓰레딩 그런 쓰레드 아님? ㅇㅅㅇ ㅡ wounded healer
ㅇㅇ 너가 말한건 쓰레드풀 얘기였구나 - dc App
Power제품 더 보니 1코어 8쓰레드 제품도 있네 ㄷ - dc App
ㅇㅇ ㅎㅎ ㅇㅅㅇ ㅡ wounded healer
난 하드웨어나 하이퍼쓰레딩 개념은 잘 몰루 ㅇㅅㅇ ㅡ wounded healer
코어에 2개 스레드 정도 두지 않음? 멀티 스레드를 쓰는 이유가 무엇임 ㅇㅅㅇ
스레드 1개에서만 처리하면, 스레드가 업무를 분할하는 퍼포먼스를 못냄. 1코어 1스레드에서 처리하는 결과가 나타남
애플리케이션에서 생성하는 단일쓰레드는 멀티코어 CPU라면 그 중에 하나만 할당하게 될 테니까 노는 코어들이 생김 ㅇㅅㅇ 멀티쓰레드 해서 코어 개수만큼 쓰레드 수를 늘려주게 되면 OS정책 등이 쓰레드별 코어를 유니폼하게 할당해준다는 전제하에 모든 코어를 활용할 수 있겠지 ㅇㅅㅇ
코어랑 자바 스레드 갯수가 1:1 이 된다고 무조건 맞는게 아님 저도 아직 그정도로 왈가발구할 실력은 안되지만, 하드웨어 스레드에서 결국에 os 스레드를 받아서 처리하는건데, 그게 코어갯수보다는 많은데 놀고있는 스레드가 발생하면 그것도 안 좋다는 말임
https://quasarzone.com/bbs/qf_cmr/views/12864
하드웨어 스레드 얘기를 하고있는거임
저도 찾아보니 하이퍼쓰레딩이 쓰레드 처리량을 늘리는데 도움이 된다고 하는게 맞는것 같음. 그렇다면 코어당 지원되는 하이퍼쓰레드 개수도 포함해서 그 가상코어(?)당 1개씩 할당하는게 맞다는게 제가 퍼온 자료들이 얘기하는 취지가 될 듯. 하이퍼쓰레딩 개념의 존재를 차치했을 때를 전제했을 때의 내용이고, 그것을 포함한 상황이라면, 좀 더 다른 설명으로서, "가급적 문맥 전환이 일어나지 않도록 쓰레드를 생성하라" 정도가 될 듯 ㅇㅅㅇ
그리고 이러한 변수도 고려해보시는게 좋을것 같음... "most experts advise against disabling HT because you may put your computer at risk"
출처:
https://www.thetechwire.com/is-hyperthreading-worth-it/
위의
자료는 2021년 11월에 씌어진 비교적 근래의 자료인데, 하이퍼쓰레딩은 그것을 켜놓으면 컴퓨터 건강에 부정적이라고 하니, 참조합시다...
반대로 하드웨어 스레드당 1개로 너무 많아지면 그것도 문제임.. JVM 같은 스레드만 돌리는게 아니잖음.. 얘를 들어 db도 한 컴퓨터에서 사용할꺼면 DB도 동시에 도니까 하나의 스레드고, 님이 말했듯 스레드가 처리하는 시간이 너무 오래 걸리면 다른 스레드로 교체 작업이 일어나니까.. 콘텍스트 스위칭 비용일듯 아마(? 비용이긴한데 확실하진 않음) 그래서 1.5~2개던데. 1코어당 4스레드까지 있기도 하니까 ㅇㅅㅇ..
https://velog.io/@agugu95/%EC%82%AC%EC%8B%A4-%EC%8A%A4%EB%A0%88%EB%93%9C%EB%8F%84-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8-%EC%8A%A4%EC%9C%84%EC%B9%AD%EC%9D%B4-%EC%9E%88%EB%8B%A4
맞네 ㅇㅅㅇ
음.. 위에서 제가 쓴 대댓글은 제가 잘못 읽은듯 disable을 enable로 읽어서 반대로 해석했네;; 끄지 말고 켜놓으라는 얘기인듯
이건 지극히 상식적인 이야긴데, 그냥 계산하고 간단한 메모리 억세스만 하는 쓰레드들은 1:1 이 유리한게 맞아. 근데 계산양도 좀 되고 IO 대기시간도 꽤 있는 쓰레드들은 계산하고 대기 계산하고 대기 한단 말이지. 그럼 그 대기시간에 다른 쓰레드가 계산을 돌아주는게 당연히 유리한거야.
이것도 간단한 예고 똑같은 시간이 소요되는 계산1, IO1 blocking, IO2 blocking 를 처리하는 경우는 쓰레드1이 IO1 으로 들어갈때 쓰레드2가 계산1을 하고, 쓰레드2가 IO1 으로 들어갈때 쓰레드3이 계산1을 하는게 낫단 말이지. 즉 3개가 도는게 낫겠지 그래서 케바케라는거야.
님이 말씀한, 케바케에서의 그 '케이스'를 결정하는게 대상 프로세스의 바운드 성격(I/O vs CPU vs 혼합 바운드)이 되는듯 ㅇㅅㅇ 결국 "(가상)코어 당 쓰레드 수의 최적비"를 기준으로 프로그램 설계를 하기 보다는, "문맥전환을 최소화 하는 가운데, 하드웨어 연산기 활용률을 극대화 하기"가 기준이 되는게 맞을 듯. 넘치지도 모자라지도 않도록... ㅇㅅㅇ
어렵게 생각할 필요없어. 그냥 돌려보고 성능체크해서 적용하면됨.
그리고 쓰레드 개수에 따라 설계가 변한다면 웃긴거라고
그런 뜻이 아니라, 님이 말씀한 것 처럼 한 프로세스 내에서 어떤 쓰레드 태스크는 I/O 바운드일 수도 있고, 다른 태스크는 CPU 바운드일 수 있음. 그러면 걔네들은 서로 상호작용을 어떻게 하게 될지는 미지수겠지만 대략적으로 걔네들 각각의 쓰레드가 (가상)코어 수의 배수 가까이 된다고 하더라도 문맥전환 때문에 성능이 떨어질 우려가 적음. 이러한 경우에는 대충 예상되는 최적의 수로 컨피그 잡아놓고, 핫리로드를 하던지 아니면 그냥 컨피그로 최적의 수를 바운드 특성이 다른 쓰레드 태스크 별로 마사지를 해주면 되겠지. 설계라고 했지만 거창한거라기 보다는 방금 언급한 쓰레드 유형별 범위 지정에 대한 컨피그 같은걸 빼놓기 정도? ㅇㅅㅇ
ㅇㅇ ㅇㅅㅇ