결국 brunch predictor가 goto문을 예측하지 못한다는 것에 기반하는 것은 사실이고, 글쓴이 말대로 무분별한 goto사용은 결국 branch hazard를 야기할 수 밖에 없기 때문에 나도 동의함.
리눅스 커널에 goto 잔뜩 쓰이기 때문에 goto가 해롭지 않다고 이야기하기 보단 거기서 goto가 가지는 의미를 가지고 해롭지 않다고 반박하는게 올바른 프린이라고 생각합니다.
하지만 안쓰기엔 goto가 너무 섹시해서 가만 놔둘 수 없음
그렇다고 쓰지는 않음
그나저나 요즘 4시간만 자는게 습관이 된건가.... 4시간 자면 강박관념처럼 일어나야해! 하고 깨어버림..... 그리고 낮에 졸음
goto가 stall을 야기한다 하는건 좀 잘못된거 같은데. 컴파일러가 최적화를 빡세게 하냐 느슨하게 하냐에 따라 달라지는거기도 하고, goto 대안책은 stall을 안내느냐고 물으면 그건 또 아니기 때문에.
ㄴ요즘 컴파일러에서 goto를 어떻게 처리함열? 내생각에는 컴파일러 최적화를 빡세게 하면 goto는 prediction이 불가능하기 때문에 다른곳에서 최적화해서 goto 땜빵하는 것 같은데.
다익스트라가 GOTO statement considered harmful를 주장한건 코드 가독성을 해치기 때문이지 성능때문이 아님.
ㄴㄴ goto가 훨씬 더 예측하기 쉽지. 무조건분기문이잖아;;
ㅇㅇ// 음 그런가... Linux kernel commonly use goto statements to get into rarely executed paths of code. It can be argued that by good programmer, goto statement is usually only used to solve exceptional situations, for example error handling/recovery. Branches ending with goto statements are predicted as not taken. 이런 글도 잇네열
여덜시간은자야함니다아그리고니들이짜는코드는그딴거신경안써도느릴이유가너무나도만이있읍니다 - dc App
sloth_//거 폭력범으로 잡혀가고 싶으십니까? 팩트한번 묵직하시네욧!
jmp 명령어는 애초에 branch prediction의 대상이 아님. je, jne같이 조건에 따라 분기 여부가 결정되는거를 예상하는거지 무조건적으로 분기하는 애는 애초에 예상이라고 할게 없는데..
그러면 branch hazard에 대한 대응으로 결국 stall밖에 없잖아열. 그냥 "무의미하게 써대면 성능저하의 원인"이라는 것이 맞는 말은 아닌가열....
ㄴ당연히 무의미하게 쓰면 성능저하가 되죠.소스코드 덩어리가 1234 순으로 있는데 goto문을 써서 1324 순으로 헤집고 다닌다 불필요한 분기를 3번이나 하니.. 그런데 애초에 저렇게 코드를 쓸거면 성능문제가 아니라 지능문제가 더 심각한거고, 똒똑한 컴파일러들은 저기서 아예 1324 순으로 컴파일을 해버려서 불필요한 분기를 아예 없애주기도함
퍄퍄 ㄹㅇ루요? 사람보다 똑똑한 기계..... 답은 goto는 특정 상황들에서 퍼포먼스 지향으로 쓰는게 좋다 인 것 같군요.
물론 위 예시는 되게 단순한 예시기땜에 멍청함이 바로 들어나지만, 코드가 충분히 복잡하면 불필요한 분기가 눈에 잘 안띌수도 있고 그것들이 실제로 성능저하를 일으킬수도 있음. 하지만 그런 경우에서도 성능문제는 코드가독성문제보다 훨씬 미미한 문제임.
협업 경험이 적은 저로써는 어렵군요....
goto문을 예외적으로 쓰는 상황이 퍼포먼스 향상용이라기보단 다른 대안보다 goto가 유별나게 가독성이 좋은 경우라 그럼. 다중포문 탈출이 대표적인 예고, return 이전에 공통적인 후처리가 필요한 경우에도 goto 쓰기도함. 후자는 핀토스 하면서 봤던 기억..
인정합니다. 너무 섹시함
애초에 goto는 브랜치 프레딕션과 전혀 무관한데 어제부터 왜 자꾸 브랜치 프레딕션 타령이냐 goto는 무조건적 점프라 브랜치 프렉디션이나 캐시 힛과 전혀 상관이 없어 - return 0;