내용이 재미 있어서 블로그로 들어갔다가 게시판이 있길래 글을 따라 쭉쭉 갔는데 엄청난 경력과

실력의 소유자이심을 알아버렸습니다.ㅋ

윈도우 프로그램인거 같은데 실례가 안된다면 프로세서 사용률좀 캡쳐해서 올려주실 수 있으신가요?

답변을 드릴 수 있어서가 아니라 저도 같이 고민해보고 싶은 내용이라서요. ^^;

일단 최적화가 안되어서 그런지 어셈 코드를 보니 완전한 직렬성을 띠고 있는것으로 보여집니다.

i[0] = 0;

i[1] = i[0] + 1;

i[2] = i[1] + 1;

       .

       .

       .

현재 연산의 결과가 바로 전 연산의 결과에 지속적으로 의존하고 있습니다.

즉, ILP 이득을 전혀 보지 못하고 있습니다.

일단 여기까지. 잘못된 내용은 다른 멤버님께서 지적 해주실겁니다. ㅋ

당연히 느려질수 밖에 없는 코드를 가지고 왜 고민들을 하시는지 이유를 모르겠네요.

본 코드는 전혀 TLP를 활용할 수 있는 코드가 아닙니다.

본 코드는 thread 개수가 많아지면 control unit, BUS, memory등에서 병목현상이 걸려 더 느려지기만 할뿐인 코드입니다.

TLP 성능 테스트를 하시려거든 spec 벤치마크를 사용하시던, EEMBC 혹은 splash2와

같은 벤치마크들을 사용해서 성능 테스트를 하시거나 아니면 TLP를 활용할 수 있는 코드를 짜서 확인하십시요.

#include <conio.h>
#include <list>
#include <stdio.h>
#include <windows.h>

typedef struct _Param
{
  int callCnt;
  int loopCnt;
  int threadCnt;
} Param;

void foo(int loopCnt)
{
  int cnt = loopCnt;
  for (int i = 0; i < cnt; i++);
}

DWORD __stdcall threadProc(LPVOID p)
{
  Param* param = (Param*)p;

  int callCnt = param->callCnt;
  // TLP를 활용하는 약간 더 올바른 예
  int loopCnt = param->loopCnt / param->threadCnt;

  DWORD begTick = GetTickCount();
  
  for (int i = 0; i < callCnt; i++)
  {
    foo(loopCnt);
  }
  
  DWORD endTick = GetTickCount();

  printf("%dn", endTick - begTick);
  return 0;
}

void usage()
{
  printf("call_loop_thread_test <call count> <loop count> <thread count>n");
  printf("example : call_loop_thread_test 100 100 2n");
}

int main(int argc, char* argv[])
{
  if (argc != 4)
  {
    usage();
    return 0;
  }

  Param param;

  param.callCnt   = atoi(argv[1]);
  param.loopCnt   = atoi(argv[2]);
  param.threadCnt = atoi(argv[3]);

  std::list<HANDLE> threadList;

  for (int i = 0; i < param.threadCnt; i++)
  {
    DWORD threadID;
    HANDLE threadHandle = 
      CreateThread(
        NULL,
        0,
        &threadProc,
        &param,
        0,
        &threadID);
    threadList.push_back(threadHandle);
  }

  for (std::list<HANDLE>::iterator it = threadList.begin(); it != threadList.end(); it++)
  {
    HANDLE threadHandle = *it;
    WaitForSingleObject(threadHandle, INFINITE);
  }

  threadList.clear();
  return 0;
}

원인을 파악 하고자 고심 하던 중 한가지 짚히는 부분이 생겼는데 백창우님 말씀과 같은 맥락이지

않을까 해서 한번 적어봅니다. 본 쓰레드는 데이터 관점에서는 공유되는 부분이 전혀 없으므로 두개의 프로세서가

각각의 L1 D캐시를 효율적으로 사용하리라 생각합니다. 하지만 코드 관점에서는 네개의 쓰레드 모두 같은 코드를

공유하므로 캐시 정책에 따라 L2, L3 캐시에 코드가 올라간다면 심각한 구조적 해저드가 발생 할 수 있지 않을까

하는 생각을 해봤습니다. 아니면 어쩔 수 없구요. ㅜㅜ

좀 놀라운데요. 답변하신 분들이 너무 쉬운 문제를 가지고 열심히 틀린 답변하시는 모습이 좀 신기하게 느껴집니다.

제가 봤을땐 질문의 내용이 하나의 일을 여러 코어에 분산하는 것이 아니라 쿼드 코어 환경에서 스레드를 하나의 생성해서 하나의 코어에 돌렸을때의 수행시간과 동일한 스레드 소스를 각각의 코어에 하나씩 수행하여 4개의 스레드를 돌렸을 때 수행 시간의 차이를 물어보신거 같습니다.

일단 제가 드는 생각은 각각 코어에서 동일 메모리 접근 시 대기하는 것도 생각 할 수 있을 거 같고, 또는 모든 코어를 이용하기 때문에 이 루프를 수행하는 도중 이 프로세스외에 다른 데몬같은 것으로 스케줄링 되어 다시 온 경우도 생각해볼수 있을것 같습니다.

안녕하세요, 이경문입니다. 에고~ 댓글이 많이 달려 있네요. ^^

이 문제에 제가 관심을 가지는 이유를 먼저 얘기를 해야 할 것 같군요. 저는 전직장에서 패킷 분석을 담당했었던 프로토콜 분석 팀장이었습니다. ISP 업체의 core망에 흐르는 네트워크 패킷을 분석해서 현황 파악(웹 트래픽이 얼마고 P2P 트래픽이 얼마고..)을 할 수 있도록 하는 것이 주 업무였습니다.

10Gbps이면 1초에 대략 100만개의 패킷(10Mpps)을 처리해야 합니다(하나의 패킷이 평균 600~1000 바이트). 예전까지는 CPU clock 속도가 계속 높아 져서 일괄 처리가 가능했었지만 시간이 가면 갈수록 하나의 CPU를 가지고는 분석하기가 어려워 졌습니다. 분석해야 하는 프로토콜도 많아 지고 패킷들도 많이 유입되기 때문이죠. 결국 높은 CPU clock 속도에 의존하기 보다는 multi threading을 통해서 패킷 분석을 하도록 (병렬로 처리하도록) 시스템이 바뀌어 갔죠.

가끔 가다 보면 급작스러운 패킷이 다량으로 발생되는 경우 패킷 손실이 나는 경우도 있는데, 이러한 경우가 발생하면 패킷 분실에 따라 분석이 어려워 져서 나중에 가면 왜 분석이 제대로 안되느냐고 제품이 납품된 회사로부터 클레임이 들어 오곤 했습니다. 아무튼 아무리 많은 패킷이 들어 와도 패킷 손실 없이 제대로 분석할 수 있도록 SW를 만드는 것이 중요한 관건이었습니다.

그 당시 납품이 되었던 장비는 NIC 카드 한장에서 수집되는 패킷을 2개의 thread에서 나누어서 처리를 하도록 되어 있습니다. 그러한 NIC 을 2장 꽂았으니, 패킷 분석 thread는 동시에 4개가 돌아 가도록 세팅이 되어 제풉이 납품되었습니다. 그런데 장비가 납품되고 나니 업체에서 질문이 들어 오더군요. 하나의 장비에 NIC을 2장만 꽂지 말고 몇장 더 꽂아서 처리하면 H/W 단가를 낮출 수 있지 않냐구요. 이 말도 일리가 있죠.

회사 내에서 실NIC 카드 한장당 10Gbps 트래픽을 분석하는 테스트를 해 보았습니다. NIC  1장 꽂으면 10Gbps를 충분히 처리합니다. NIC 2장 꽂으면 20Gbps도 잘 처리하구요. 그런데 3장 이상 꽂으니 30Gbps 분석을 제대로 하지 못하고 패킷 손실이 나기 시작하는 겁니다(당시 사용했던 장비의 CPU는 core가 8개였던 것으로 기억함). 결론적으로 하나의 장비에는 NIC 카드 2장을 꽂아서 사용하는 것이 제일 효율적이라는 귀납적 결과만 도출하고, 그 정확한 원인 분석은 하지를 못하였습니다.

간단하게 나타내 보자면 다음과 같이 되겠습니다.

NIC 1장 / 분석 thread 2개 / 10Gbps 처리 잘 함

NIC 2장 / 분석 thread 4개 / 20Gbps 처리 잘 함

NIC 3장 / 분석 thread 6개 / 30Gbps 처리 잘 못함

어찌 되었건 간에 정확한 원인을 알고 있는 것이, 나중에 이와 비슷한 시스템을 재설계할 때 도움이 될 것 같아서 질문을 올려 본 것입니다. Computer Architecture를 제대로 파악을 하자 못하니 정확한 원인 규명이 어렵네요.

질문의 요지는 "thread간의 자원의 동기화 코드(critical secion 혹은 mutex 등)도 없고, 자신의 thread를 blocking(I/O)시키는 부분도 없는 코드를 실행시켰을 때 thread 갯수가 늘어 날 때마다 수행속도가 늦어 지는 이유는 무엇일까?"입니다. 물론 thread 갯수는 CPU 갯수보다 작거나 같습니다. ^^

아, 그리고 테스트를 해 보니 하나의 thread만을 돌렸을 때 해당 코드를 수행하는 CPU는 어떻게 될까 테스트를 해 봤는데, 테스트할 때마다 달라 지더군요. 하나의 CPU만 사용되기도 하고, 어떨 때에는 2개의 CPU에 나누어 실행되기도 하고... 아무래도 thread scheduling 정책에 따라, thread의 CPU 할당을 OS가 마음(?)대로 결정지어서가 아닐까 하는 생각만 듭니다. thread time slice 시간을 변경하면 context switching에 들어 가는 cost를 줄일 수 있을까 하는 생각도 해 보았는데, 이건 저 능력 밖의 일... -_-;

동영상으로 찍어 보려고 했었는데 동영상 찍는 프로그램(camtasia)자체도 CPU를 먹어 버려서 동영상으로 찍기가 쉽지는 않더군요. ^^

관련 동영상 올려 봅니다. 하나의 스레드의 실행이 여러 CPU에서 돌아 가는 동영상입니다.

thread affinity로 검색하니 윈도우 API로는 이런 함수가 있네요... SetThreadAffinityMask

리눅스에도 이와같은 API가 존재할듯 하네요... 원하는 결과를 얻게 되었으면 좋겠네요...