태그 : 위치로그 : 방명록 : 관리자 : 글쓰기  
 
Study, Study, Study!
공부하자!
  카테고리
전체 (102)
cache (51)
interc... (2)
schedu... (13)
OS Issues (5)
power (7)
simula... (1)
Memory (1)
Archit... (17)
ILP an... (3)
applic... (1)
  공지사항
  달력
«   2012/01   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
  태그
  최근에 올라 온글
: Reducing Cache Misses Usin...
: dynamic hardware-assisted ...
: Better than the Two : Exce...
: SOS: A Software-Oriented D...
: Fairness via Source Thrott...
  최근에 달린 댓글
: 잘 지내긴 -_- 읽기만 ...
: 은지야. 애-_- 키우다 ...
: 이번 주 연구실 세미나...
: 앗 감사합니다. 블로그 ...
: PACT 08 에서 DIP의 단...
: simple is the best라는...
: MapReduce를 보면서, 특...
: 오늘은 내가 졸려서 내...
: DATE, 2006
: MICRO'2006
  최근에 받은 트랙백
  링크
  글 보관함
Total : 57935
Today : 85
Yesterday : 175
Get RSS Page XML RSS2.0
Powered By TatterTools
Skin By Foradun.com
Edit By Badung.net
 
2007/02/06 15:12 2007/02/06 15:12
 Dual-Core Execution: Building a Highly Scalable Single-Thread Instruction Window - Architecture Variant/ETC : 2007/02/06 15:12
PACT05 년도 논문. 대충 읽었음.

CMP에서 single-thread APP의 성능도 중요. multi-core는 parallel은 잘 돌아가는데 serial은 memory wall이 문제.
CMP를 이용해어 large instruction window를 구현한다. 두개의 superscalar core를 q로 연결하고
front-core에서는 수행을 하는게 아니라 가짜 수행을 해서 branch prediction을 하고 data cache warm-up을 해준다.
back core에서는 실제 수행을 하는데 front core에서 넘겨준 request queue에 있는 순서대로 instruction을 수행한다.
이런 식으로 해서 수행을 쓸데없이 두번 시키긴 하지만 back core에서 수행시 성능이 올라간다.

front core에서 수행시에는 cache에는 data를 안쓰고 RA cache를 그 안에 둬서 거기에 data를 써가면서 수행을 하고
실제 결과값들이 real하게 cache나 memory로 내려가지 않게 되고, 혹 prediction이 틀렸을 경우에는
모든걸 전부 flush하고 re-execute. 하는 방식으로 구현.

그래서 결국 memory stall시간을 줄였고 branch prediction accuracy도 높여서 성능 향상을 보였다.
related work인 runahead 방식보다도 더 좋은 성능을 보였고, 이거야 core가 두개니 그런가.. 머 잘 모르겠다.
여튼 그렇게 성능 향상을 시켰음.
관련글0 : 댓글0


이 글의 관련글 주소 : http://naivete.isloco.com/trackback/2301166






↑top