박문형 2017-06

어찌보면 이유는 간단한데요..

씨피유가 세대가 올라갈수록 씨피유가 지원하는 명령어 셋이 계속 늘어갔고

영상쪽은 H264코덱도 씨피유 안에 하드웨어적으로 넣었다라고 봐야 하기에

클럭이 낮아도 최신세대 씨피유들은 특히나 영상쪽 처리가 무지 빠릅니다..

열마니 나고 전기 마니먹고 메모리 작은 것들은 이제 다 가따버리던지

박물관 컬랙션 해야 합니다..

최만용 2017-06

이 결과가 세팅의 차이가 아니라면, 그 말씀이 전적으로 옳겠습니다..  그냥 관상용으로나 쓰겠는데요..
그래도 코어가 많아서 조금은 인코딩에 더 낳겠지 했는데 완전히 틀린 생각이었네요.  HDD가 SSD냐 SATA Raid 냐는 저정도 크기의 동영상이면 크게 상관이 없겠죠?

쓰레기단장 2017-06

인코딩시에 코어를 다 못 쓰는경우가 꽤 있습니다. 프로세스 분할과 다르게 프로세스 1개에서 스레드를 나누는 경우는 스레드 동기화 비용에다가 작업 우선순위 때문에 노는 코어가 생기기 쉽고 그게 다 비용으로 직결됩니다. 그리고 네할렘과 하스웰 정도의 세대 차이면 코어당 IPC 성능차이도 무시 못하구요 클럭 차이도 꽤 나기 때문에 하스웰이 이긴 것 같아요. 납득못할 결과는 아닌 것 같습니다. 명령어 지원 여부는 크게 중요하지 않을 거라고 봅니다.

진정한 CPU 100프로는 컴파일.... 경험상 컴파일시에는 코어 많은 게 장땡이더라구요.

딸기대장 2017-06

맞을껍니다...
전자제품이 그렇게 시대에 역행하면... 인텔이 잘 나갈리가 없죠...

최만용 2017-06

아이고... 아까워라.
전기세 무서워 비록 저전력CPU들로만 해보았지만 그냥 내다 팔고, 카비CPU나 하나 더 사서 간촐히 만드는게 더 좋을듯 하네요. 흑흑

최만용 2017-06

듀얼의 위용? 진가?를 실감할 수 있으려면 적어도 어느정도의 CPU로 꾸미는게 체감이 될까요?
싱글보다 못하는 저녀석들은 뭐에 써야 아깝지 않을까요??  전기도 많이 묵는데...^^

박문형 2017-06

전기 마니 먹어도 쓸만하다고 보이는 것은 DDR3 베이스 시스템들입니다..

집에서는 X58 , 5590을 사용중에 있습니다만
(바꿀려고 눈치 보는 중)

듀얼 5690으로 16기가 12개 정도 풀뱅 해버리면 아직은 충분히 씁니다..

최만용 2017-06

우... 들인 돈이 아까워서, 5690 듀얼을 사야하나 생각이 드는데, 이게 또 하염없는 낭비가 될지...흑흑

gmltj 2017-06

가상머신 많이 굴리는 용도 같은거가 아니면 코어 수가 많아봐야 전력 소비만 많아서 그다지.....

최만용 2017-06

가상머신은 한번 안해보았는데, 이것 많이들 사용하시는 듯 합니다. 시스템 1대로 운영하실때... 어려울듯 해서 보고만 있는데, 이참에 해볼까 봐요..아까워서

ADDA1234 2017-06

L5420은 하퍼타운이네요..45nm 펜린 쿼드코어.. 클럭 스피드가 2.5GHz인데다가 SMT미지원 IPC 차이으로 인해..바이바이하고..
L5640은 그래도 웨스트미어라서 방어가 어느정도 되는군요. 50%이하 로드율에 1275L V3와 비슷하다면 싱글로도 비슷하다는 이야기인데..

웨스트미어급이면 아직까지는 그래도 쓸만하다? 결론이 나오는군요. 물론 세월은 무시 할 수 없고 10년이면 강산이 바뀌는 세월이라는데..네할렘이 2010년 웨스트미어가 2011년쯤 나온걸로 알고 있는데..하스웰은 2014년이죠?

웨스트미어-하스웰-카비레이크는 아직 쓸만하다. 는 결론..? 카이레이크 7600은 SMT가 없어서 인코딩은 하스웰과 크게 차이는 안날듯 하네요.

최만용 2017-06

I5-7600 카비레이크 가지고 있는데, 이것으로 오늘 한번 해 볼 요량입니다.  넘 오래되었군요...결국..

김승현1 2017-06

이미 너무 세대차이가 많이 납니다
저도 서버로 사용하는게 i7-4765 4c8t인데

이전 시스템인 x5650듀얼과 제가 하는 인코딩범위안에선 비슷하더군요

늘파란전상태 2017-06

그냥 최신 1CPU 제품에 코어 수 많은게 장땡인듯 합니다....

그렇지 않아도....인텔 AMD 가 서로 코어수 전쟁 들어갔으니.....

구형 2CPU 제품과 신형 1CPU 코어수 다수 제품과의 성능차이.....전력차이는 더 커지겠죠...

최만용 2017-06

이 말씀이 맞는것 같습니다.  그냥 추억은 추억으로 냄겨둘걸 그랬어요..

쓰레기단장 2017-06

코어 많은 시스템을 구축하신 분들이 이런 벤치마킹을 해 보고 실망하시는 경우가 많습니다.

일단, 멀티스레딩에서 제일 중요한 것은

1. 제대로 결과를 뽑아 내야 한다.
2. 노는 코어를 최소한으로 만들어야 한다.

입니다. 예를 들어 볼께요.

int sum = 0;
int array[4] = { 1, 2, 3, 4 }
for(int i = 0; i < 4; ++i)
{
    sum += array[i];
}

위는 단순하게 수열의 합을 구하는 코드입니다. 쉽게 말해서 sum = 1 + 2 + 3 + 4 인 것이지요. 이것을 듀얼 코어 시스템에서는 다음과 같이 최적화할 수 있습니다.

int sum = getsum(array, 2) + getsum (&array[2], 2);
int getsum(int* array, int arraysize)
{
    int sum = 0;
    for(int i = 0; i < arraysize; ++i)
    {
        sum += array[i];
    }
    return sum;
}
getsum 함수는 따로 스레드 코드를 넣지 않았습니다만, 뭐 대충 스레딩 했다고 칩니다 ㅋ; (사실은 스레드 API말고도 두 코어 계산의 결과를 기다리는 코드도 있어야 합니다)
쉽게 말해서 sum = 1 + 2 + 3 + 4 였던 것을 sum = (1 + 2) + (3 + 4)로 바꾸고 (1+2)연산을 코어 하나에, (3+4)를 다른 코어에 할당해서 성능을 높인 것입니다.

위 코드를 보면 싱글스레드에 비해 2스레드로 돌린다고 성능이 두배 올라가지 않는 이유가 보입니다. 마지막 sum계산은 앞의 getsum(array, 2) 스레드와 getsum (&array[2], 2) 스레드가 둘 다 끝나기를 기다려야 하기 때문입니다. 반면 두 getsum() 스레드는 서로간에 간섭 없이 돌릴 수 있지요. 예로 든 코드는 결국 최후의 getsum() + getsum()연산은 동시성을 취할 수 없지만 복잡한 코드의 경우는 이렇게 동시성을 취할 수 없는 (즉 스레딩이 불가능한) 코드를 최소화 하는 것이 스레드 잘 쓰는, 그리고 코어 잘 쓰는 방법입니다. 그리고 CPU사용량 측정 방식은 한 스레드가 다른 스레드의 계산 결과를 기다리고 있어도 스레드가 사용하는 코어 사용량은 100%입니다. 아무 것도 안 하는 주제에 말이지요.

그럼 왜 멀티스레드가 아닌 멀티프로세스는 더 CPU를 잘 사용할 수 있나면, 보통 프로세스는 서로 간섭 없이 독립적으로 돌아가기 때문입니다. 물론 프로세스간 통신을 하는 API가 있긴 합니다만 비용도 비용이고 구현 난이도가 올라가기 때문에 프로세스간 통신을 많이 해야하는 경우는 두 프로세스를 스레드화 해서 돌리는 편이 낫기 때문입니다. 따라서 프로세스로 CPU코어의 사용을 분리하는 건 꽤 용도가 한정되어 있습니다. 보통 컴파일러가 그렇지요. 컴파일링은 obj파일을 만들 때 꽤 독립적으로 돌릴 수 있습니다. 그래서 컴파일이나 렌더링의 경우는 코어 개수에 따라서 수직적으로 성능이 올라갑니다. 그 외의 멀티 스레드 로직은 크든 작든 동시성 문제와 연산 순서 문제를 가지고 있으며, 덤으로 동시성과 연산순서 지정을 위해 사용하는 mutex에 관해서는 데드락과 같은 더 골치 아픈 문제도 가지고 있습니다. 또 그 외에도 CPU로 가면 컨텍스트 스위칭의 효율 문제도 있습니다. 컨텍스트 스위칭은 하나의 코어가 여러 개의 스레드 혹은 프로세스를 처리할때 어쩔수 없이 시분할 방식으로 코어가 여러 개의 프로세스를 돌아가면서 조금씩 처리하는데 이 때 프로세스를 교환하는 것을 말하고 이것이 비용이 꽤 비쌉니다. 그래서 mutex를 사용할 때 내가 쓸 만큼 쓰고 다음 프로세스로 코어 사용권을 넘기느냐, 아니면 차라리 조금 남았으니 내 꺼 다 처리하고 내 프로세스를 종료하는 것이 결과론적으로 더 코어를 잘 사용하는지를 판단해야 하는 것이고, 이것도 케바케이기 때문에 꽤 어려운 결정입니다.

그 외에도 멀티코어 시스템에서는 복잡하고 골치 아픈 이슈가 꽤 있습니다. 이 중 많은 부분은 유저가 걱정할 것 없이 커널이 최적화를 해 주고 그 외의 부분이 프로그래머가 고민해야 하는 부분입니다. 그래서 코어 많은 시스템보다 ipc가 높고 클럭 높은 시스템이 유리한 경우가 더 많다고 생각합니다. 가급적 쉽게 쓰고자 했는데 제가 말하고자 하는 바가 잘 전달될지는 잘 모르겠습니다. 그 점은 미리 죄송하다고 말씀드릴게요. ^^;

김영기 2017-06

가..강좌급 댓글이군요!
언젠가 궁금해서 여쭤보니, 멀티코어 퍼포먼스를 보존하는 프로그래밍은 프로그래머 직함 달고있다고 아무나 할 수 있는게 아니라고 답변들 해주시더라고요.

최만용 2017-06

늦게 보았고, 전문적인 말씀이다 보니 모두 다 이해를 하지는 못했겠지만,
" 마지막 sum계산은 앞의 getsum(array, 2) 스레드와 getsum (&array[2], 2) 스레드가 둘 다 끝나기를 기다려야 하기 때문입니다."
==> 요 문장으로, 이해가 좀 되었습니다.  이런문제를 프로그래밍에서 해결하기가 그냥보기에는 불가능? 해 보이네요... 로직인데...

프로그래밍은 일자무식이지만, 덕분에 듀얼프로세스에 대해서 좀 더 이해가 되었습니다.
감사합니다.^^

laputa 2017-06

으흐..  댓글이 어마무시한.. 범접할수없는 느낌을 줍니다..
저도 장터에서 x79  rampage 4 formula 와 2680 v2 ES 버전을 구입해 조립했습니다.
그런데 요놈이 win10은 잘되는데 win7은 설치가 안되서 지금 문의게시판에 글 올려 놓았습니다.
저는 포토샵위주로 작업하는데 포토샵도 코어 보다는 클럭빨이 중요하다고 하네요..    해보고 아니다 싶으면 방출하려 합니다. ^^

최만용 2017-06

으으... 저는 이거 팔지도 못하겠고, 전기세 좀더 나와도 조금더 빠르다는 X5675로 해서,
마음의 위안이라도(인코딩 속도가 좀 빨라지면...) 삼을까 고민중입니다...ㅡㅡ;

그냥 장남감으로 쓰다 2011소켓으로 갈까 싶기도 한데, 이 장난감이 쓸모가 없어져서...흑