섣부른 최적화를 할 능력은 되고?

Рет қаралды 9,505

Күн бұрын

Пікірлер: 61

@발언계산기 2 жыл бұрын

섯부른 최적화 하지마라 = 망치질 안끝났는데 연마하지마라 섯부른 최적화하지말랬어. 이것도 안해도 돼 = 망치질 중이니까 들쑥날쑥 두드릴꺼야 포프: 망치질은 효율적으로 일정하게 두드리는 것이 당연하고, 연마는 나중에 하는 것이 당연하다.

@샤린히르곤 2 жыл бұрын

한방에 이해했습니다^^

@발언계산기 2 жыл бұрын

@@이세진-e8j 영상은 잘생긴 포프님 얼굴보기위해 다 봐야합니다. 2번보세요

@johnsim8102 2 жыл бұрын

너무 좋은 예시네요 ㅋㅋ 저는 오늘 남이 두드려놓은 구부러진못을 장도리로 후벼파내고 펴낸다음 다시박는 작업을 했습니다. 연마는 할 엄두가 안납니다 ㅋㅋ

@발언계산기 2 жыл бұрын

@@kinu-u3k 교정 감사합니다.

@phw1009 2 жыл бұрын

괜히 아무도 모르는 알고리즘 적용해서 수식 하나로 만들어 버리고, 나중에 보면 "????" 하는 코드보다는 차라리 가독성이 좋게 만들어 놓고 제품이 완료된 이후 '개선'의 필요성이 있을 때를 위해 남겨두라는 말씀이시군요

@sanmaro91 2 жыл бұрын

포프님은 밥도둑.. 요즘 밥먹으면서 잘보고있습니다.

@포프티비 2 жыл бұрын

저때문에 살찌시면 안되는데....

@MJ-rs7js 2 жыл бұрын

보통 시간 대비 의미 없는 최적화에 집착하지 말라고 하는 말이지 그냥 코딩 짜면서 바로 그렇게 짤 수 있는 요소들까지 알 필요없고 하지 않아도 된다는게 아닌데...

@leeds6361 2 жыл бұрын

한국에는 풀스택개발자 캠프 100일과정 등등이 생기고 있습니다. 최적화, 경량화라는게 될 지 모르겠네요. 트렌드라고는 하지만 내공보다는 스킬 배워서 취업들을 하시는 분들이 늘어나셔서 씁쓸합니다.

@user-fn1wf9zg2i 2 жыл бұрын

베이스 전혀 없는 사람들 데려다가 100일만에 풀스텍 개발자 양성하는 건 아니겠죠 설마..?

@포프티비 2 жыл бұрын

프로그래머 직군이 폭이 넓어진거죠. 단순사무직부터 엔지니어 급 까지!!

@jaylee4976 2 жыл бұрын

게임 프로그래밍 학원 선생님이 어설픈 최적화 해봤자 2~3프레임 빨라지고 코드 가독성만 나빠지니까 그런거 고민할 시간에 쓸데없는 형변환이나 값복사 막고 멤버변수 초기화나 제대로 하라고 했었는데 그 말이 이런 뜻이었군요.

@olok95ify 2 жыл бұрын

협업할때 서로 쉽게 이해할 수 있는 공통의 코드… 정말 설득력있는 문장 배워갑니다

@choing8604 Жыл бұрын

++i나 i++나 똑똑한 컴파일러는 동작에 임시변수가 굳이 필요없는 부분에서는 같은 속도로 동작하는 머신코드를 뱉겠지만 내 코드가 어떤 멍청한 컴파일러를 만날지 모르니까...

@하이젠버그-b3b 2 жыл бұрын

확실히 cpp 를 사용하면 자꾸 병적으로 최적화 하고 싶은 욕구가 있긴하죠. 다만, 분야에 따라서 좀 갈릴 듯 합니다. 연산의 비중이 적은 정보 관리 관련된 분야에서는 DBMA에서 대부분 연산을 하니 그쪽에서는 체감이 안되죠. 반대로 사양이 낮은 임베디드 환경에서 실시간으로 1/50초 간격으로 센서값 같은거 일정한 주기로 읽어오게 하려면 논리 연산의 or 연산자의 경우 사용 금지 항목이죠(하지만, 주니어는 그냥 써놓고 성능 낮은 MCU 탓하고 있더라). 덤으로 제 기억에는 수학자들이 C로 작성한 함수 렌더링 예제 보면 for문에 거의 ++i 만 쓰더라고요.

@hhstyner 2 жыл бұрын

17년전에 프로그래밍 배운지 1년 됬을 때 가르쳐 주시던 형님이 말해주셔서 처음 들었고 수년 뒤에 대학교 들어가서도 2학년 수업 중에도 들었던 기억이 있는데 2022년도에 이런 주제의 이야기를 뭔가 해명? 설득? 하듯 나오는거 보고 있자니 뭔가 찡~ 하네요

@포프티비 2 жыл бұрын

요즘은 6개월 단기 학원 나와서 취업을 하기도 하니 이런 부분을 제대로 들을 기회가 적어진 거 같아요

@chrisshim2488 2 жыл бұрын

0비교가 값비교 보다 빠르니까 i--로

@포프티비 2 жыл бұрын

--i 로....

@정재빈-b7o 2 жыл бұрын

3번째에 말해주신 Class 생성자에서 초기화를 하지않고 assignment(?)를 하면 안된다는게 어떤 의미인가요? Class 초기 생성자를 만들지 않으면 비효율적이 된다는 의미인가요?

@정재빈-b7o 2 жыл бұрын

관련 자료가 있으면 읽어보고 싶어서 그러는데, 구글링 키워드나 링크 알려주시면 감사하겠습니다!!

@포프티비 2 жыл бұрын

C++ class member initializer

@komdols 2 жыл бұрын

섣부른 최적화... 많이 공감되네요. ㅎㅎ 호출횟수를 줄일 생각은 안하고 instruction한개 줄일 생각만 하는 그런 느낌? 이네요.

@lebkete 2 жыл бұрын

영상 굉장히 좋다고 생각합니다 이런 영상은 곱씹어서 생각해야 한다고 생각해요. 언제나 스스로 점검합니다..!

@김민규-i4c7c 2 жыл бұрын

arr[++i] = num; 과 arr[i++] = 에서 전자의 경우 ++i의 값을 계산하고 arr의 인자에 접근할 수 있는 데 반해 후자의 경우 i를 증가시키는 것과 arr의 인자에 접근하는 동작을 동시에 할 수 있어서 의존성 체인 면에서 오히려 i++가 나을 때도 있다는 이야기를 들었는데 혹시 맞나요?

@포프티비 2 жыл бұрын

2개는 아예 결과가 다르지 않나요? 따라서 성능 비교의 대상은 아닌 것 같습니다. 그리고 i증가와 접근을 동시에 할 수 있다는 것도 잘 이해가 안 되요. 싱글스레드에서 어떻게 그게 가능하지.... 근데 몇년 전쯤에 i++가 더 빠를 수도 있단 자료는 본적이 있긴합니다. 어떤 상황이었는지는 정확히 기억이 안나요

@김민규-i4c7c 2 жыл бұрын

#include #include #include void __attribute__((noinline)) f1(char *dest, char *str) { int count = -1; for (int i = 0; str[i]; ++i) if ('0'

@민기-q1v 2 жыл бұрын

@@김민규-i4c7c글쓴이님 ++count 부분 초기값 0에 배열크기만 +1해서 테스트 다시 해보실 수 있나욥

@김민규-i4c7c 2 жыл бұрын

@@민기-q1v 오 그렇군요 오늘 오후쯤에 한번 해보겠습니다 감사합니다

@김민규-i4c7c 2 жыл бұрын

@@민기-q1v 해봤는데 유의미하다고 느껴지는 실행속도 변화는 없습니다. 여전히 O1에서 3%, O2에서 9%정도 arr[count++]가 빠릅니다. 근데 제가 위에서 언급을 안 한 게 있는데 이게 네이티브 리눅스에서 측정한 게 아니라 WSL2에서 측정한 결과입니다.

@정규이-e6w 2 жыл бұрын

포프님 지금 무슨 노트북 사용하시나요,

@포프티비 2 жыл бұрын

여전히 carbon x1 사용합니다. 이제 5~6년 된 랩탑이겠네요

@정규이-e6w 2 жыл бұрын

@@포프티비 답글 감사합니다

@YoungSoo815 2 жыл бұрын

알고리즘 공부하고 있는데요, 알고리즘 선생님이 ++i 전위표기의 경우 컴파일러에 따라 i++ 특성으로 동작하기도 해서 i++로 사용하라고 들었는데요 예를 들면, int a = 0; int b = ++a; 인 경우 일반적으로 b는 1이지만 컴파일러에 따라 0인 경우도 있다고 하네요 맞는 얘기일까요? 영상 주제와는 다르지만 궁금해서요

@포프티비 2 жыл бұрын

++i가 컴파일러에 따라 i++ 특성으로 동작하는 경우는 어떤 상황을 말하는지 감이 안와서 제가 어찌 드릴 말씀이 없습니다. (선생님이 잘못 알고 있거나 아니면 어떤 특수 상황을 말씀하시는 건데 제가 그게 뭔지 이해못하고 있거나) 전위/하위 증감이 컴파일러 따라 행동이 달라지는 건 명확한 Sequence point가 없을때 undefined behavior가 일어나기 때문이 거의 대부분일텐데.... 들어주신 int b = ++a; 는 그 경우도 아닙니다. 그리고 이건 어느 컴파일러에서도 b 는 1이라고 알고 있습니다. 이것에 대해 궁금하시면 Sequence point undefined behavior란 검색어로 검색해 보세요.

@user-ig9su3jq9d 2 жыл бұрын

업계인입니다. int main void main같이 표준비표준문법도 아니고 후임전위연산자는 엄연하게 동작자체가 다른데 컴파일러가 굳이 느린 후임연산자로 바꾸는 컴파일러가 뭔지 궁금하구요. 적어도 제가쓰는 컴파일러에는 없네여. 그리고 요즘은 ++i로 쓰는경우들이 더 많죠. 사실 c++11부턴 인덱스를 쓰는경우가 많이 줄긴했지만 NULL==Ptr처럼 지금은 이렇게 쓰는경우가 적죠. 후임연산자로 도는경우도 적어지고있습니다.

@홍지환-f1q 2 жыл бұрын

감사합니다. :)

@scarab72 2 жыл бұрын

전위증감은 뭐다요

@jahyukshin4239 2 жыл бұрын

for(int i=0; i

@scarab72 2 жыл бұрын

@@jahyukshin4239 미대나온 사람이라 뭔말인지 모름....후루루루루

@scarab72 2 жыл бұрын

@@haeyongHwang 포프아재 구독중이라서.

@scarab72 2 жыл бұрын

@@haeyongHwang 업계친구가 소개해줘서 몇년전부터 보게되었는데 재미있잔아여

@euns8565 2 жыл бұрын

멤버쉽까지하셨네 ㅋㅋㅋㅋㅋ

@hoon4694 2 жыл бұрын

일반적인 값증가면 사실상 거의 대부분++i 로 코딩하는게 좋은 습관인게 맞나요? 회사에서나 여기저기보면 여전히 i++이 압도적으로 많아서 이젠 제가 잘못안건가 의심이 들때가 있더라구여. 최적화때매 차이가 거의없는건 알구있음다. 게임쪽 이야기 입니다.

@무명-u4q 2 жыл бұрын

최적화 때문에 차이가 없어지는 경우도 있고 최적화가 불가능한 경우도 있습니다 STL의 이터레이터들이나 사용자 정의 클래스의 경우에는 최적화가 힘들어서 ++i가 낫죠 흔히 쓰는 기본 정수형 타입에 대해서는 매우 높은 확률로 최적화가 되겠지만 개인적으로 굳이 최적화를 전제하고 코딩할 필요가 있나 싶어서 항상 ++i로 씁니다

@하이젠버그-b3b 2 жыл бұрын

분야와 업계 문제죠. 포프님이 언급한 것 처럼 1/60 초내에 조금이라도 빨리 연산하려면 좋은 습관이지만, 게임이 아닌 일반적인 응용프로그램이나 정보를 표시해주는 경우에는 별로 체감이 안되죠. 자신이 배우는 환경과 자신의 의지 차이죠(대부분 교재에서는 i++로 많이 표기 되어 있으니...). 다만 확실한거는 가독성의 차이는 별로 없는 경우 조금이라도 더 빠른게 낫긴하죠.

@hoon4694 2 жыл бұрын

@@무명-u4q 소중한 답변 감사합니다!

@hoon4694 2 жыл бұрын

@@하이젠버그-b3b 소중한 답변 감사합니다!