예전의 그 커피숍 문제,
나는 수식을 다 치환해서 정수 영역에서 풀었엉.
big integer 를 간단히 구현해서 만들었지.
문제에서 +-100만 이런 dynamic range 가 나오면 정수영역 가감산에서 유효자리수 문제 없이 최적화 할 수 있다는 힌트일 뿐.
코세횽 뜬금없이 댓글 달아서 죄송한데,, 코세횽 글보면 속도나 성능 중요시 하던데 이런 것에 대해 조금이라도 감을 잡으려면 어떤걸 알아둬야할까요? 컴파일러론이나 운영체제 쪽 공부해야하는지,,,,
컴파일러론과는 아주 무관하구요.
컴퓨터 아키텍쳐 100%, 디지틀 논리회로 5%, 실제 컴퓨터 아키텍쳐가 구현된 CISC / RISC 프로세서의 명령어 구조의 대표적 공통점. 컴파일 후 결과물을 disassemble 해서 비교해 볼 수 있는 정도의 어셈블리능력, 이 기본이 되고
실험을 잘하면 됩니다.
너무 막연하고 떠먹여달라는 식의 질문하기 싫은데 아예 감이 안잡혀서 질문했는데 힌트를 얻었네요 ^^ 항상 감사해여 코세횽
가장 주로 쓰이는 지식은 pipeline 과 scalar, memory addressing, data cache, code cache 정도의 개념이죠. 나머지는 연산 별 성능 파악 정도.
SIMD 를 알아두면 금상첨화 : )
결국 우리가 데이타를 가져다 연산을 하는걸 코드로 표현하는데, 데이타를 가져오는 과정도 변수나 값, 포인터나 배열 정도로 표현될지라도, 그 내부적 움직임은 훨씬 세세하거든요.
address bus 를 통해 주소를 보내고 control bus 를 통해 읽기나 쓰기 요청을하고 data bus 를 통해 값을 전달하거나 읽어오는 과정이 시스템마다 응답속도가 다르니까
그런것들을 스펙 데이타시트를 통해 얻거나, 통제변인을 포함한 실험을 통해 더 거시적으로 구하거나 하면 되는거죠.
아 검색해봤는데 말씀하시는 내용들의 대부분이 정말 컴퓨터 아키텍쳐 책 목차에 다 들어있네요 짱짱!!
이런게 또 FPGA 로직을 통해 HDL 로 CPU 비슷한걸 설계해 보다 보면 아, 이렇게 만들수 밖에 없겠구나. 라던가 이렇게 만들면 효율적인데 인텔 쟤네 참 띨빡하네. 그런 아이디어도 생길수 있죠. 그러면 나중에 척보면 척~
본질적으로 파고들면, 해당 operation 이 synchonized 냐 async 냐 의 기저설계에서 생기는 문제들이란걸 알 수 있어요. 성능을 위해서 중첩을 하자면 async 를 쓰게 되니 비슷한 코드도 조그마한 차이로 다양한 성능 스펙트럼을 갖게 되는 것이죠.
그러니까 우리가 atomic 하다고 생각하는 단순한 증가 명령 하나에도 사실은 내부적으로 async 하게 구현되어 있다는거죠.
CPU 와 RAM 이 분리된 설계에서는 베이스 클럭이 다르니 sync 를 구현하는게 낭비가 심하고, 단일 베이스 클럭을 공유하는 CPU 내부에서도 논리적으로 다양한 응답클럭을 갖게 되기 때문에 병렬화를 위해서는 논리적 async 구조가 필수가 되는 것.
아아 ,, 그런식으로 성능 차이가 생기는 거군요 ^_^ 정말 고마워여!!!
My pleasure~
문제에서 +-100만 이런 dynamic range 가 나오면 정수영역 가감산에서 유효자리수 문제 없이 최적화 할 수 있다는 힌트일 뿐.
코세횽 뜬금없이 댓글 달아서 죄송한데,, 코세횽 글보면 속도나 성능 중요시 하던데 이런 것에 대해 조금이라도 감을 잡으려면 어떤걸 알아둬야할까요? 컴파일러론이나 운영체제 쪽 공부해야하는지,,,,
컴파일러론과는 아주 무관하구요.
컴퓨터 아키텍쳐 100%, 디지틀 논리회로 5%, 실제 컴퓨터 아키텍쳐가 구현된 CISC / RISC 프로세서의 명령어 구조의 대표적 공통점. 컴파일 후 결과물을 disassemble 해서 비교해 볼 수 있는 정도의 어셈블리능력, 이 기본이 되고
실험을 잘하면 됩니다.
너무 막연하고 떠먹여달라는 식의 질문하기 싫은데 아예 감이 안잡혀서 질문했는데 힌트를 얻었네요 ^^ 항상 감사해여 코세횽
가장 주로 쓰이는 지식은 pipeline 과 scalar, memory addressing, data cache, code cache 정도의 개념이죠. 나머지는 연산 별 성능 파악 정도.
SIMD 를 알아두면 금상첨화 : )
결국 우리가 데이타를 가져다 연산을 하는걸 코드로 표현하는데, 데이타를 가져오는 과정도 변수나 값, 포인터나 배열 정도로 표현될지라도, 그 내부적 움직임은 훨씬 세세하거든요.
address bus 를 통해 주소를 보내고 control bus 를 통해 읽기나 쓰기 요청을하고 data bus 를 통해 값을 전달하거나 읽어오는 과정이 시스템마다 응답속도가 다르니까
그런것들을 스펙 데이타시트를 통해 얻거나, 통제변인을 포함한 실험을 통해 더 거시적으로 구하거나 하면 되는거죠.
아 검색해봤는데 말씀하시는 내용들의 대부분이 정말 컴퓨터 아키텍쳐 책 목차에 다 들어있네요 짱짱!!
이런게 또 FPGA 로직을 통해 HDL 로 CPU 비슷한걸 설계해 보다 보면 아, 이렇게 만들수 밖에 없겠구나. 라던가 이렇게 만들면 효율적인데 인텔 쟤네 참 띨빡하네. 그런 아이디어도 생길수 있죠. 그러면 나중에 척보면 척~
본질적으로 파고들면, 해당 operation 이 synchonized 냐 async 냐 의 기저설계에서 생기는 문제들이란걸 알 수 있어요. 성능을 위해서 중첩을 하자면 async 를 쓰게 되니 비슷한 코드도 조그마한 차이로 다양한 성능 스펙트럼을 갖게 되는 것이죠.
그러니까 우리가 atomic 하다고 생각하는 단순한 증가 명령 하나에도 사실은 내부적으로 async 하게 구현되어 있다는거죠.
CPU 와 RAM 이 분리된 설계에서는 베이스 클럭이 다르니 sync 를 구현하는게 낭비가 심하고, 단일 베이스 클럭을 공유하는 CPU 내부에서도 논리적으로 다양한 응답클럭을 갖게 되기 때문에 병렬화를 위해서는 논리적 async 구조가 필수가 되는 것.
아아 ,, 그런식으로 성능 차이가 생기는 거군요 ^_^ 정말 고마워여!!!
My pleasure~