기글 하드웨어 소프트웨어 포럼
소프트웨어와 인터넷에 관련된 이야기를 자유롭게 나눌 수 있는 곳입니다. 게임에 관련된 글은 게임 포럼을 이용해 주세요.
웹브라우저 벤치마크로 부하를 준 후 각각 CPU 점유율을 살펴보면, 현재 쿼드코어인 제 시스템에서(Q6600 2.4GHz) 절대 개별 점유율이 25%를 넘지 않더군요.
물론 단일 브라우저에 작업 부하를 준 후 CPU 사용 현황을 보면 대체적으로 4개 코어가 고르게 부하를 받는 걸로 봐선 멀티코어를 사용한다고 볼 수도 있지만, 단일 프로세서 CPU 점유율이 25%가 한계라는 것은 현재 웹 브라우저들이 아직 멀티코어를 제대로 지원하지 못하는 것이 아닌가 싶습니다.
현재 브라우저들이 성능 향상을 위해 대체적으로 사용하는 기술이 전통적으로는 자바스크립트 등 웹에 쓰이는 기술 처리를 효율적으로 해서 속도를 높이는 것과, 최근엔 GPU 가속을 이용해서 웹페이지에 렌더링되는 결과 처리를 빠르게 하는 것이 있는데 차후엔 현재 PC에선 거의 대세가 된 환경이며 모바일 부분에선 슬슬 도입이 시작되는 멀티코어를 지원하는 것에 신경써야 하지 않나 싶네요.
말인즉슨, 현재 어떻게 해도 n코어 CPU의 1/n만 사용하는 웹브라우저가 멀티코어를 제대로 지원하게 된다면 웹브라우저 속도는 n배만큼 빨라진다는게 되니깐요.
2010.12.23 11:04:51
CPU 업그레이드보다 SSD 같은 스토리지 성능의 향상이 더 크게 느껴지는 것을 볼 때, 입출력 속도가 더 중요해 보이더군요. 그리고 플래시를 로딩하지 않으면 가벼워지는 것이 쉽게 체감되는만큼, 플래시가 문제일 가능성이 더 커보입니다.
2010.12.23 11:15:01
제대로 사용 안 해도 좋으니까 스마트폰은 제발 빨리 Cortex A-9MP2 사용폰들이 많이 나왔으면 좋겠어요.
그럼 플래시에 의한 부하가 좀 분산될테니까요.
그런면에서 GALAXY S2에 Orion이 꼭 들어다가길 바라는 1인
그럼 플래시에 의한 부하가 좀 분산될테니까요.
그런면에서 GALAXY S2에 Orion이 꼭 들어다가길 바라는 1인
2010.12.23 11:33:50
결코 프로세서가 n배 늘어난다고 n배 빨라지지는 않습니다. 프로그램에는 병렬화가 불가능 한 부분이 있기 때문이죠. 그렇기 때문에 병렬화하지 못하는 부분을 줄이거나 계산량을 늘려야 합니다. 웹브라우져의 경우 자바스크립트는 설계 자체가 싱글스레드 기반이고 소켓 통신 등 입출력 처리 부하가 높은 작업이 주를 이룹니다. 마크업랭귀지 파싱등에 멀티코어를 활용할 수는 있겠지만 일반적으로 웹서핑이라는 게 페이지 하나에 높은 부하가 걸린다기보다는 여러 페이지를 동시에 열어 놓는 경우가 많기 때문에 하나의 페이지가 n개의 프로세서를 다 쓰게 하기 위해 노력할 필요성이 별로 없습니다. 의외로 병렬화에 드는 비용은 상상을 초월합니다.
2010.12.23 11:39:17
사용합니다. 웹브라우저들은 워낙 스레드를 많이 쓰니까 굳이 병렬형으로 설계 안해도 멀티코어의 활용도가 굉장히 높죠 -_-
웹브라우저의 발목을 잡는건 오히려 cpu보다 입출력 장치의 병목이 큽니다
플래쉬로 덕지 덕지 도배된 사이트가 아니라면 cpu사용률이 높은걸 보기는 힘들겁니다
왜냐면 페이지 로딩시에만 부하가 순간적으로 몰리기 때문이죠 -_-a
웹브라우저의 발목을 잡는건 오히려 cpu보다 입출력 장치의 병목이 큽니다
플래쉬로 덕지 덕지 도배된 사이트가 아니라면 cpu사용률이 높은걸 보기는 힘들겁니다
왜냐면 페이지 로딩시에만 부하가 순간적으로 몰리기 때문이죠 -_-a
2010.12.23 20:02:38
웹브라우저가 또 그런 문제가 있군요.
그리고 위 상황은 플래시를 돌린 상황이 아니라(파폭의 경우엔 탭브라우징때문에 플래시가 보입니다), Peacekeeper같은 플래시를 사용하지 않는 웹브라우저 벤치마크시 상황입니다. 차후 플래시 대신 HTML5 요소들이 대중화된다면 충분히 그것만으로도 시스템 자원을 높게 소비할 수 있는 부분이죠.
뭐 대충 구글링해보니깐 하나의 창에서 멀티코어를 이용하는것보다 실질적인 작업 상황인 여러 창을 띄워놓고 하는 작업에서 각 창마다 코어를 이용하게 하는 방향으로 나가는것 같네요.
그리고 위 상황은 플래시를 돌린 상황이 아니라(파폭의 경우엔 탭브라우징때문에 플래시가 보입니다), Peacekeeper같은 플래시를 사용하지 않는 웹브라우저 벤치마크시 상황입니다. 차후 플래시 대신 HTML5 요소들이 대중화된다면 충분히 그것만으로도 시스템 자원을 높게 소비할 수 있는 부분이죠.
뭐 대충 구글링해보니깐 하나의 창에서 멀티코어를 이용하는것보다 실질적인 작업 상황인 여러 창을 띄워놓고 하는 작업에서 각 창마다 코어를 이용하게 하는 방향으로 나가는것 같네요.
2010.12.27 06:46:03
비단 웹브라우저 뿐만 아니라 현재 프로그렘들이 exe의 형태로 돌아가는 이상 어쩔 수 없다고 봅니다.
이미 exe로 묶어서 하나의 단일 프로세스화시킨 프로그렘을 실행해서 램에 상주시키고
돌렸을때 강제로 다시 멀티스레드화 시키는건 상당히 비효율적이기 때문이죠.
또 병렬화라는게 사실 애매한 부분이 있는데
진짜로 해당 프로그렘의 소스 자체를를 2개 이상의 스레드로 분배시키는 병렬화는 정말 어렵습니다.
하나의 프로세스가 n개의 스레드를 동시에 이용하기 위해서는 그의 소스의 양이 n제곱으로 늘어난다고 보셔도 됩니다.
이러느니 차라리 아예 CPU와 OS 자체가 필요할때 한개의 프로세스를 2개 이상의 스레드로 동시에 같이 연산시킬 수 있어야 합니다.
지금 이게 대부분 잘 안되기 때문에 멀티코어의 이상향과는 거리가 좀 떨어져있는게 사실입니다.
구글 크롬처럼 탭이나 플러그인 등의 여러 내부 프로세스를 따로 독립된 프로세스로 램에 상주시키는게 그나마 현실적인 병렬화입니다.
소스 자체가 병렬화된건 아니지만 그럭저럭 퍼포먼스나 효율은 괜찮죠.
이미 exe로 묶어서 하나의 단일 프로세스화시킨 프로그렘을 실행해서 램에 상주시키고
돌렸을때 강제로 다시 멀티스레드화 시키는건 상당히 비효율적이기 때문이죠.
또 병렬화라는게 사실 애매한 부분이 있는데
진짜로 해당 프로그렘의 소스 자체를를 2개 이상의 스레드로 분배시키는 병렬화는 정말 어렵습니다.
하나의 프로세스가 n개의 스레드를 동시에 이용하기 위해서는 그의 소스의 양이 n제곱으로 늘어난다고 보셔도 됩니다.
이러느니 차라리 아예 CPU와 OS 자체가 필요할때 한개의 프로세스를 2개 이상의 스레드로 동시에 같이 연산시킬 수 있어야 합니다.
지금 이게 대부분 잘 안되기 때문에 멀티코어의 이상향과는 거리가 좀 떨어져있는게 사실입니다.
구글 크롬처럼 탭이나 플러그인 등의 여러 내부 프로세스를 따로 독립된 프로세스로 램에 상주시키는게 그나마 현실적인 병렬화입니다.
소스 자체가 병렬화된건 아니지만 그럭저럭 퍼포먼스나 효율은 괜찮죠.
작성된지 2주일이 지난 글에는 새 코멘트를 달 수 없습니다.