올해도 어김없이 퀄컴 IT Tour를 뽑습니다. 올해로 벌써 11기째 모집하는 행사이고, 저는 9기로 갔다왔었습니다. 어떤 행사인지는 전에 작성한 포스트를 보시면 간략하게 확인하실 수 있습니다.2012/03/20 - [About Me] - Qualcomm IT tour 10기를 모집합니다.이공계 생이 취할 수 있는 가장 좋은 공모전 행사가 아니었나 싶습니다. 물론 저도 대외활동을 많이 한 것은 아니지만요. 그래도 퀄컴이라는 글로벌 기업의 본사에 찾아가서 회장도 만나보고 체류비용을 일체 지원해주기에 부담없이 잘 갔다왔었습니다. 무엇보다도 그때 만났던 사람들과의 인연이 아직까지도 이어지고 있다는게 저한테는 큰 의미로 작용하네요.아무튼 궁금하신 분들은 링크에 명시된 정보를 이용하시면 되겠습니다. 그래도 감이 ..
지난 포스트를 통해서 Finite Automata를 잠깐 언급했다. 사실 써놓고 무슨 내용인지는 나 자체도 이해가 안가지만 특정 문구를 뽑아내기 위한 Regular Expression이 나오면 이를 Finite State 형태로 구현하는 것 자체가 Finite Automata 라고 했던 것 같다. 즉, 오른쪽의 수식을 하나의 State Diagram으로 변환해주는 과정 자체가 Finite Automata를 구현하는 단계라고 볼수 있다. 위의 수식은 표현하자면 state를 나눠놓고 0일때의 입력이 어떻게 들어왔느냐에 따라서 state의 변화 정도를 표현한 것이다. 예를 들어 첫번째 입력이 a로 들어오면 b가 들어올때까지 state가 유지되는 것이다. Regular Expression 식도 그 이전 포스트에..
지난 포스트에서 Write Policy를 다뤄봤다. 그럼 강의에 언급된 예제를 다시 되짚어보고자 한다. 이렇게 생긴 Cache block이 있다. 이와중에 Memory로부터 다음과 같이 연속된 Memory Sequence를 읽어오려고 한다. Cache는 과연 어떻게 쓰여질까?0, 4, 8188, 0, 16384, 0 일단 첫번째 0을 읽어오게 되면 Cache의 0번 index 값을 검색하게 된다. 이 후에 Tag가 맞는지를 확인해야 되는데 Cache에는 아무처리가 되어 있지 않으므로 당연히 Cache Miss가 발생하게 된다. 그럼 이전 포스트에서 언급했던 내용처럼 Write Policy에 따라서 Memory로부터 받아온 Data를 해당 Cache block에 채워넣게 된다. 4를 읽어왔을 때도 마찬가지..
이전 포스트에서 Cache와 Memory사이의 Data를 검증하는 과정을 다뤘다. 마지막 부분에서 과연 Cache miss가 났을때는 해당 instruction을 다시 수행하면서 다시 fetch하는 과정이 들어가는데 이때 Cache의 write이 이뤄지게 된다. 그럼 어떤 규칙에 의해서 cache에 써지는 지 잠깐 언급해보고자 한다. 일단 Cache 본연의 목적을 살펴보면 Memory Access하면서 얻을 Data의 일부를 옮겨놓음으로써 쉽고 빠르게 Access 하기 위함이다. 당연히 Memory와 Cache간의 Consistency가 중요한 요소이며 이걸 고려하면 당연히 miss가 안나는 방향으로 설계가 되어야 할 것이다. 가장 간단한 방법은 Cache에 write이 일어날때 같은 Data를 Memo..
지난 포스트를 통해서 Cache를 사용하면 어떤 이점을 가져올 수 있을지에 대해서 다뤄봤다. 그러면 이런 궁금증을 가져볼 수 있다. Cache 자체가 Data Access 측면에서 Memory에 비해 이점이 있다면 왜 Cache를 쓰지 Memory도 같이 쓰는 건지 말이다. 사실 얼마든지 생각해볼 수 있는 주제일 수 있지만 문제는 바로 cost의 관점이다. Architecture를 설계하는 데 있어서 고려해야 될 가장 중요한 요소는 바로 얼마나 싸게 만들 수 있냐는 것이다. 즉 가격대 성능비를 고려해서 설계하는 것이다. 물론 Cache를 많이 넣으면 그만큼 빨라지겠지만 Cache를 구성하는 SRAM의 가격이 비싸고, 공간도 적다. 거기에 비해서 지금과 같은 DRAM Memory가 lower level에 ..
Computer Memory의 일반적인 역할은 Data를 담아두고 있으면서 CPU가 순차적으로 접근해서 그안에 들어있는 Instruction을 읽어오게끔 하는 것이다. 그러면 다음의 과정을 생각해보자. Processor와 Memory은 각각의 모듈이기 때문에 서로간의 신호를 주고 받기 위해서는 Bus라는 통로를 거치게 된다. 만약 우리가 이 안에 있는 정보를 확인하고 싶으면 I/O를 통해서 관찰할 수 있는 것이다. 그런데 이런 것들이 공통의 bus를 사용하기 때문에 당연히 한계가 있을 것이다. 가령 예를 들어서 한꺼번에 Data가 이 Bus를 통해서 전달이 되면 Bottle neck 과 같은 성능을 저하시킬 수 있는 요소도 존재할 것이다. 그러면 컴퓨터 구조를 설계하는데 있어서 추구해야 될 목적 중에는 ..
미국시간 3월 18일을 기점으로 kinect SDK v1.7와 Kinect Developer Toolkit v1.7.0이 공개되었습니다. 한동안 키넥트 관련 내용을 정리하지 않고 있었긴 하지만 이번 포스트에서 뭐가 바뀌었는지 한번 다뤄볼 예정입니다. 간단히 체험해본 바로는 MS가 완전 Kinect를 게임의 수단이 아닌 연구의 목적으로 개발하기 시작했다고 생각합니다. 무엇보다도 관심을 끄는 것은 바로 OpenCV(왠일로?)와 결합했다는 겁니다. 다들 알다시피 OpenCV는 Open Source로 공개되어 있는 Vision Library인데 상업용으로 개발된 SDK와 결합하는 방법을 소개했다는 건 정말로 시사하는 바가 큽니다. 물론 이전 버전도 놀라운 예제들이 포함되어 있지만 왠지 다음에 공개될 v1.8에서..
System을 설계할 때는 두가지 접근 방식이 있다. 하나는 Monolithic Approach이고 다른 하나는 Do-It-Yourself Approach이다. 사실 생각해보는 사람에 따라서 어떤 접근 방식을 취하느냐가 다를 수 있는데 Realtime System의 경우에는 Monolithic Approach가 적합하지 않다. 왜냐하면 Realtime System 자체가 여러개의 모듈의 결합으로 만들어진 경우가 대부분이기 때문에 뭔가를 하나로 뭉뚱그려서 정의를 할 수 없다. 또한 경우에 시간에 따라 system의 결과물이 가변적이기 때문에 이 또한 정의하기가 힘들어서이다. 그 대신 어떤 기준 모델에 대한 정의를 할 필요성은 있다. 이전 포스트에서 잠깐 언급했던 workload라는 기준으로 Referenc..
지난 포스트에서 Pipeline이라는 기법을 살펴보았다. 이에 따른 자료는 Open Source Software Learning Center(http://olccenter.or.kr)에 공개되어 있는 민상렬 교수님의 강의를 바탕으로 정리해보고 있다. 아무튼 Pipeline을 하는 이유는 instruction을 stage에 나눠서 순차적으로 적용할 수 있게끔 해서 전체적으로 Sequential Execution 보다 처리되는 시간을 줄이고자 하는 것이 목적이었다. 하지만 모든 기술 구현에는 trade-off가 존재하고 Pipeline을 구현하는데 있어서도 operating Speed를 줄이는 장점을 가져올 수 있긴 하지만 이에 따른 문제가 몇가지 발생한다. 이걸 전문 용어로 Hazard(위험) 이라고 하고..
어제 집에 오니까 딱하고 편지가 와 있네요. 마침 그 날 google I/O 2013 를 접수받는 당일이라서 뭔일일까 싶었는데.. 원래 오기로 한거였더군요. 아시는 분들도 계시겠지만 제 블로그에는 구글에서 제공하는 adsense가 설치되어 있습니다. 제 블로그는 무광고를 표방하고 지식의 공유를 표방하기에 최대한 포스트와 관련없는 내용들을 메인에서 배제하려고 노력합니다. 실은 이것도 html5를 테스트 해보려고 단 목적인데 지우는 것도 틀이 안 맞는 거 같기도 해서 놔두고 있습니다. 제 광고는 메뉴줄 하단에 있으며 제 블로그 내용에 공감이 가시는 분이라면 한번씩 눌러주시면 감사하겠습니다. 아무튼 Adsense의 수익금이 10불이상이 되면 위와 같이 구글 본사로부터 편지가 날아옵니다. 여기에 담겨있는 정보를..
이제 대학원에서 공부하는 시간이 많아지고 덕분에 교양서적 보다는 전공 서적과 함께하는 시간이 많아졌습니다. 그래도 여유가 있을 때는 전공에서 벗어나 새로운 분야를 접하고 그에 관한 책을 읽으려고 노력하고 있습니다. 이번 여유 시간에 읽은 것은 반준철씨께서 쓰신 오래가는 UX 디자인이라는 책입니다. 사실 이 책 서문에도 언급되어 있지만 요즘 UI/UX라는 단어가 범람하고 있습니다. 당연히 편의를 추구하는 기준이 예전에는 단순히 기능이 많은것을 요구했었지만, 이제는 기능이 단순화되면서 사용자 관점에서 얼마나 편리하게 사용할 수 있느냐를 목적으로 개발되고 있습니다. 그런데 요즘에는 이 UX의 정의가 너무 남발되고 있다는 생각이 들기도 합니다. 사람들이 UI/UX라는 말만 붙으면 인기가 좋으니까 본래 참뜻보다는..
Computer Organization & Design 책을 보면 pipeline 파트의 맨 처음에는 다음과 같이 언급되어 있다.Never Waste Time. 동서고금의 명언이다. 아마 이 말이 pipeline을 하는 이유를 설명한 가장 간단한 구문이 아닐까 생각을 해본다. 말그대로 pipeline을 하는 이유는 시간을 낭비하지 않기 위함이다. 잘 모르는 사람이라면 컴퓨터가 사람이 시키는 대로 연산을 하는 건데 어떤 부분에서 시간을 낭비하는 건지 의아할 수도 있다. 하지만 그건 결과론적으로 본 것이고, 그 내부를 살펴보면 컴퓨터 동작 중에서 시간을 낭비하는 요소들이 곳곳 존재하는 것을 확인할 수 있다. 컴퓨터는 기본적으로 연산을 자동화해주는 기기이긴 하지만 무엇을 연산할 건지, 어떻게 연산할 건지는 컴..
이전 포스트에서 계속 다룬 내용은 Compiler 의 동작 수행시 가장 먼저 이뤄지는 Lexical Analysis 이 뭔지를 살펴보고, Regular Expression을 통해서 코드 상의 string을 뽑아낼 수 있는 것을 보았다. 이렇게 살펴보면 사람이 작성한 코드는 무척이나 많은 요소들로 구성되어 있는 것을 알 수 있다. 먼저 alphabet들이 있을 것이고, 그 alphabet으로 구성된 string이 있을 것이다. 그 중 의미를 지닌 keword도 들어갈 수 있다. 또는 어떤 연산을 위한 Number도 들어가 있고, Operator, Bracket, Whitespace 등등이 사람이 작성한 코드에 적어도 하나씩 포함되어 있다. 그러면 이전 포스트에서 말한 Regular Expression 방법..
지난 포스트에서 했던 이야기를 다시 해보자면 컴파일러가 하는 역할은 사람이 작성한 코드를 컴퓨터가 인지할 수 있게끔 번역해주는 역할이며, 가장 먼저 선행되어야 할 기능이 구문을 Token별로 잘라주는 Lexical Analysis이었다. 이를 위해서는 구문을 잘라내기 위한 특정 Pattern이 필요한데 보통 이걸 Regular Expression 방식을 사용해서 처리한다고 언급했었다. 이번 포스트에서는 그 Regular Expression에 대해서 조금 정리해보고자 한다. 우선 String의 구성요소에 대해서 알아볼 필요가 있을 듯 하다. 보통은 구문 또는 단어라는 말로 다들 알고 있다. 그럼 이 String을 잘게 쪼갤 수 있을까 한번 Compiler라는 단어를 예로 들어보자우선 첫번째 구성요소는 접두..
- Total
- Today
- Yesterday
- Policy Gradient
- DepthStream
- ai
- Offline RL
- Kinect
- arduino
- Pipeline
- Kinect SDK
- Expression Blend 4
- RL
- reward
- End-To-End
- 딥러닝
- PowerPoint
- windows 8
- TensorFlow Lite
- Distribution
- SketchFlow
- processing
- 강화학습
- Windows Phone 7
- Gan
- Kinect for windows
- bias
- ColorStream
- 파이썬
- dynamic programming
- Variance
- Off-policy
- 한빛미디어
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |