최적화는 설계단계에서 고려해야한다.
vs
설계 후 제작과정에서 개발하면서 최적화를 한다.
vs
개발 후 디버깅과정에서 혹은 최적화 과정을 따로 기간을 잡는다.
유익한 토의 주제 하나 던져봅니다
프갤럼(210.102)
2016-12-02 04:22
추천 0
댓글 100
다른 게시글
-
프갤러들이 쓸모없는 논쟁을 그만하고 좀더 유익한 토론을 했으면 [40]익명(118.47) | 16.12.02추천 0
-
아으 잠 안 와웹땔감dz(118.33) | 16.12.02추천 0
-
세상에 다 봐 버렸다. [3]codesafer(codesafer) | 16.12.02추천 0
-
솔직히 코세형 오타쿠에 과대망상맞죠? [6]익명(223.62) | 16.12.02추천 19
-
피곤하고 머리아픈데프갤럼(210.102) | 16.12.02추천 0
-
낄낄이랑 고딩지인중에 자살한애랑 비슷하다 [2]asdf(175.223) | 16.12.02추천 3
-
ㅇㅇ 너무 불쌍하다 개도 주인이 개 위한다고asdf(175.223) | 16.12.02추천 0
-
이런 고요하고 밀도 있는 시간엔 가치 있는 일을 하는거다. [16]codesafer(codesafer) | 16.12.02추천 0
-
ㅇㅇ 저거 자기 리플만 지우는 병신인줄 알았는데 [3]asdf(175.223) | 16.12.02추천 0
-
형들아 이거 숫자 왜 이런가요????????????????????ㅇ(125.177) | 16.12.02추천 0
요구사항 수집이 온전히 끝났다는 확정은 돌려보고 깨닫게 되는 경우가 많아서. 괜히 경험 없이 지엽적 최적화를 했다가 다시 풀었다가 할 가능성이 큼.
개발할 때 저는 코드짜면서 계속해서 수정하면서 메모리랑 연산 부하를 고려하게 되는데 너무 쓸데 없을 정도로 집착하는 것 같습니다
그때그때 노트라니... 좋은 방법이네요!
그리고 최적화란게, 최소 논리가 아닌 코드의 량이 불어나거나 복잡해지는 최적화는 보통 재사용성이 급감하게 돼.
저는 한번 짠 소스는 다시 사용하지 않습니다(?)
그래서 원래의 최소 논리를 보관해두는게 좋아. 다른 함수명이면 좋지.
오호 꿀팁이네요
한 번 짠 소스를 다시 사용하지 않는게 젊었을때의 겪게 되는 흔한 상황이지.
근데 코딩스타일이 완성되면, 했던거 또 하는게 정말 짜증남.
배우는 입장에서는, 띄어쓰기 칼 맞추구, 최적화 하고, 네이밍 다듬는게 시간낭비같지.
어차피 다른거 할 일이 많으니까.
아직은 젊은 혈기로 밀어붙일 수 있지만... 저도 결국 자주쓰는 놈들은 모아서 라이브러리처럼 만들겠지요...
대충 테스트 코드 짜는 정도에서 정성들일 필요는 없다고 생각해.
아항 알겠습니다
하지만, 고급 이상으로 코딩 스킬이 올라가게 되면 이때부터는 재사용할 수 있는 코드를 만들 자격이 돼.
저는 재사용성을 전혀 고려하지 않고 프로젝트 끝나면 파일 짱박아두고 잊어버려서 문제가 큰 듯 합니다
그건 괜찮아. 내가보기엔, 넌 새로운 경험들을 많이 해봐야 되는 시기야.
니 문제는 재사용성을 고려하지 않는게 아니라,
문법과 알고리즘, 경험의 바탕이 부족하다는거야.
흐음... 그런가요 ㅎㅎ
역시 저는 코더꾼일 뿐이지요
그게 없이는 쓰기편한게 안나와. 쓰기 불편한데 재사용하면 뭐하겠어.
그게 니 문제지. 코더라고 한정지으니까.
넌 전자인데 소프트웨어를 한시적 필요에 의해서 한다고 생각하고 있으니까. 그릇이 작은데 비올때 내놔본들 물이 많이 차겠니.
프로그래밍으로 컴공 애들을 쩜쪄먹겠다는 생각 없이 고수가 될 순 없어.
잔기술은 느는 것 같은데 핵심이 안늘어서 조금 서글픕니다 ㅠ
각오와 노력의 문제야. 코더일 뿐이죠. 이러면 겜 셋이지. 총 안들고 맞아 죽으러 전쟁터 나가는셈.
원래 안하면 안 늘어. ㅋㅋㅋ
그건 니 재능의 문제가 아님.
노력의 문제지.
잘 짠 코드를 분석하고 니껄로 뺏겠다... 그런 생각이 없어서 그래.
노오오오오오오오력이 부족하군요 ㅋㅋㅋ 뭐 그건 당연한 이야기지만요.
그런 생각만 있으면 책도 필요없어. 이건 암기의 문제는 아냐. 첨에 요령이 없을땐 암기가 좀 필요하지만.
뛰어난 예술가는 베끼고 위대한 예술가는 훔친다.
늘 하는 말이잖아.
그걸 행하지 않으면 위대해질 수 없지.
아는걸 행하지 않는게, 나태함과 비겁함이지. 그러고 찡찡댈거면, 그건 다른 사람의 시간을 뺏는짓이야.
코딩책은 임베디드 최적화 다루는 책 가벼운 마음에 산 것 말고는 없지만.... 음 확실히 이건 납땜과 같은 느낌이라 생각합니다. 하면서 느는
컴퓨터 아키텍트 랑 운영체제는 무조건 떼고 봐야돼.
그거 못 떼고 프로그래밍의 고수가 될 순 없어.
사실 자료구조다 뭐다 해봐야 쓰는거 빤하고, 배열과 링키드 리스트만 알아도 나머진 다 파생되거든.
예외가 있다면 소팅 정도.
그것들만 기본에 충실하게 공부하고 나면, 넌 그제서야 프로그래밍을 하게 된거야.
아키텍트는 배웠는데 운영체제는 배운적이 없어서리 따로 공부해야하는데 으으으으으으 배울 것은 많고 저는 너무 나태하군요
1. 프로그래밍이 재밌고, 2. 컴퓨터 구조와 운영체제를 제대로 알고, 3. 기본적인 문법과 자료구조의 기초 정도만 알아도 사실 찡찡거릴 이유가 없어.
아키텍트를 배웠으면, 니가 Instruction Fetch Cycle 에 대해 잘 설명할 수 있어야겠지?
Pipeline 과 Scalar 에 대해 설명할 수 있어야겠지?
할 수 있어?
난 배웠다고 말하면서 핵심이 뭔지 모르고, 설명 못하는 사람들을 너무 많이 본다. 그건 배운게 아니야. 시간낭비한거지.
당연한건데, 볼펜을 새로 사면 잘 안나오는 경우가 있어.
어떤 선을 그어야 할 때, 그러니까 니 머리에 어떤 분야의 지식을 넣어야할 때,
학습법, 공부법, 배우는법 이란걸 사용해서 펜을 긋는거야. 근데 잘 나와. 선이 막 끊어져. 똥이 끼고.
선이 끊어진 채로, 나 그었다. 하는게 이상한거야.
그럼 또 그으면 돼. 이어지지 않은 선을 긋든 전체를 덮어서 긋든 또 긋고 긋고 하면 결국 채워져
되게 쉬워.
니 머리가 아예 고장난 볼펜이었다면, 넌 고등학교 입학을 못했음.
덜 그어진 거의 안그어진 선을 놓고. 저기다 그었었으니까 배웠다. 라고 생각하는게 널 망치는거야.
알겠어?
파이프라이닝은 어느정도 기초는 설명할 수 있는데 스칼라는 뭔지 모르겠군요... 여튼 부지런히 공부하고 코드 짜야겠군요 ㅠㅠ
@양자얽힘 그럼 data hazard 와 branch hazard 를 알겠네?
아세유?
데이터해저드는 str이나 ldr과 같은 다수 싸이클을 요하는 명령어가 파이프라이닝을 통해 진행 될 시에 빈 싸이클을 추가해야하기 때문에 그걸 제거하기 위해 넣는 부분 아닌가열? 브런치도 비슷했는데 쓰는 일이 없어서 까묵까묵.... 아 다시 공부해야지....
근데 보통 이런 해저드들은 씨퓨 설계당시에 어느정도 다 커버쳐서 설계되어 나오지 않나열
빈 싸이클이 아니구 버블. 그 현상을 스톨 이라고 하지.
응 즉, 파이프라인이 깨지는 경우를 설명하는 두가지 경우가 데이타와 브랜치지.
아 맞아 스톨... 기억난당!
왜 파이프라인 가속을 먹지 못하는가... 왜 성능이 떨어지는가...
데이타 해저드는 write back 되기 전에, 결과값을 대기하는, 연산적 의존성 때문에 발생하고
흐음... 그렇군요....
맞아요 배운거 기억이 아직 죽지 않았네요...
브랜치 해저드는 기껏 미리 다음 명령어들 Fetch 하고 Decode 하고 Execute 하려는데,
어 분기해야되네~ 그럼 그 다음꺼 미리 읽어놓은게 다 무용지물이네~ 해서 다 버리게 되는거잖아. 어~ 이 산이 아닌갑다. 하는거지
그래서 데이타 해저드를 해결하기 위한 방안이 있고,
아 기억난다!! 난다요 기억이!!
그걸 비종속적 명령의 재배치라고 하지 영어 타이핑이 귀찮다.
브랜치 해저드를 해결하기 위한 방안이 있으면 좋겠지만, 그건 없지.
그래서 브랜치는 없애버릴 수 있으면 좋은것. 하지만 없애기 위해 연산이 무진장 늘어나거나, 너무 느린 연산을 쓰게 되면 독이지.
내가 무분기 코드를 좋아하는건, 분기 없애는 연습을 어릴때부터 했기 때문이지.
퍄퍄
즉, Instruction Fetch Cycle 을 이해한다는건, 파이프라인의 배경 기반 구조를 이해한다는거고
파이프라인을 이해한다는건, 코어의 클럭에 비해 파이프라인의 단계만큼 가속할 수 있다는걸 이해하는거고
해저드를 안다는건, 그런 가속이 정상 동작하지 못하는 원인을 찾아, 최적화 할 수 있다는걸 말하는거지.
이해됨? 이걸 알면 써먹을 수 있지.
즉 파이프라인과 스칼라는, 코어 하나 내부에서 이루어지는 병렬화고, 때때로 이런 병렬화, 즉 비동기 방식에서 종속성이나 분기가 발동할때 동기화됨을 의미하는거야.
코어 하나 내부의 병렬화 문제지. 이걸 잘 알면 남들보다 훨 빠른 코드를 만들 수 있다.
그럼 연봉이 올라가지.
간단.
저는 아직 그정도 수준이 안되는 것 같습니다 ;ㅂ;
이걸 지식으로 가졌다면, C/C++ 코드에 반영해야함.
그러기 위해서는, 니가 생각해서 재배치하고, 분기를 제거한 경우가, 그렇지 않은 경우보다 빠른지 느린지, 얼마나 빠른지 알아야 하고
양자얽힘//됬->됐 (되어 = 돼임) [리듬 맞춤법 봇♬]
내가 올려놓은 bench.h 같은걸 이용해서 측정하면서 코딩하면 니들이 스스로, 지식의 가치를 더 높게 실현할 수 있지.
흐엉 갈길이 멀군요! 부지런히 해야겠습니다
넵 그렇습니다.
단일 코어 내부 병렬 프로그래밍이죠. 우리가 흔히 병렬 프로그래밍 이라고 하는건 멀티 쓰레딩 혹은 멀티 프로세싱 이고, 여러개의 코어일때 의미가 크죠.
더 넓은 범위 그러니까 컴퓨터 간의 병렬화를 보면 분산 처리나, 그리딩 이 나오는거죠.
아 너무행복하다
이해할 수가 있다니
시스템 소프트웨어 과목 너무 좋다