꽃중년보넥스
-1k
2020-08-18 04:38:22
28
2442

CPU는 충분히 빠르지 않다..


CPU는 충분히 빠르다는 의견에 대하여

반론을 제기하겠습니다.


영상분석, 파싱, 이미지프로세싱, 암호화(복호화), 크롤링등

CPU에게 제대로 일을 시키는 물량공세를 해소하는 일을 시켜보면

현대의 CPU는 충분히 빠르지 않다는 것을 쉽게 알 수 있습니다.

로우레벨의 코어엔진에서는 if문 하나에

인간이 체감할 수 있는 정도의 변화가 있기도 합니다.


요즘의 CPU는 3~5GHz입니다. 1초에 30억개의 명령어를 실행하죠.

근데 10년전에는 얼마였는줄 아시나요? 2~3GHz입니다.

10년동안 1.5배 빨라졌습니다.


잠깐 다른 이야기를 하자면

CPU 최대의 고민은 분기처리입니다.

요즘 CPU 내부의 알고리즘은 예측실행을 합니다.

하나의 CPU는 다수의 ALU(산술처리)등 내부적 병렬시스템이 있지만

하나의 스레드가 하나의 CPU이므로 모든 소프트웨어는

하나의 스레드관점으로 보자면 절차적 실행이라는 한계가 있고

CPU의 내부적 병렬시스템을 충분히 활용하지 못하기에

CPU는 예측실행이라는 과정을 통해 각종 분기적 요인까지

미리 연산을 수행해 버립니다.


그런데 이 분기적 예측이 틀릴 경우 롤백을 하게 되는데

이게 270틱을 소모하는 정도의 큰 손해를 야기합니다.

그래서 if는 그 자체로 손해를 야기하지 않지만

자주 true/false 결과가 달라지는 if는 큰 손해를 야기합니다.

VM은 많은 시스템이 동일한 분기연산 메모리위치에 의해

돌아가니 if의 CPU예측이 상당히 많은 손해를 야기하게 됩니다.

VM은 그래서 안되는 겁니다. 다른 원인도 있겠지만 이게 핵심입니다.

그러나 C++은 템플릿이 있구요. 매크로가 있습니다.

둘다 조금씩 다른 사용성에 따라 바이너리가 갈라져 버려서

분기예측이 크게 이익보는 장사인 셈입니다.


각설하고 다시 본론으로 돌아와서.

CPU가 아무리 많다고 하여도 영상분석이라던지 파싱, 암호화등.

직렬로 수행하지 않을 수 없는 것들이 꽤 있습니다.


자율주행에도 쓰이는 영상분석 알고리즘이 CPU의 느린 사정을 고려하여

얼마나 간단함을 추구하고 있는지를 한번 느껴보고.

OpenCV같은 기반기술이 늦은 속도를 고려하여 많은 요인들이 생략된

쨉실이를 추구하고 있음에도 얼마나 느린지를 한번 느껴봐야 합니다.

문자인식(OCR), 얼굴인식(FaceTraking)도 의외로 상당히 느립니다.

쉬운 영상의 경우 50ms가 걸리기도 하지만 어려운 영상의 경우엔 1000~3000ms도

걸리는 것이 현실입니다. CPU가 아무리 많아도 절차적이라 나누어 일할 수가 없죠.


제 차(Jag/2019)가 주행시 차선트래킹이 됩니다만 깜짝 놀랬습니다.

느릴땐 2~3초가 걸리는 겁니다. 빠를땐 0.5초정도. 틀리기도 합니다.

트래킹부분의 소프트웨어 최적화는 다른 차들과 유사하다고 봅니다.

테슬라의 오토파일럿은 저도 안타봤지만 타본 사람의 말에 따르면

오토파일럿이 작동되는 지역은 따로 있으며 모든 길을 갈 수 있는 것이 아니라

내비게이션으로 목표를 지정하면 오토파일럿 가능여부를 확인해야 하며

날씨등 조망상태에 따라 실패하기도 하며 수시로 핸들을 놓을 수 없다고 합니다.

해당 도시는 GPS정보가 다르다는 썰도 있답니다. 머 이해가 됩니다.

위성GPS는 오차범위가 무려 10m거든요. 여튼 각설하고.


양자컴퓨터같은 것이 나오지 않으면 CPU가 갑자기 변할 리는 없습니다만

양자컴퓨터같은 것이 막 내년에 대중화되어 나오고 그러겠습니까? ㅎ

또한 모바일시대입니다. 데스크탑 전성시대보다 오히려 더 느려졌습니다.

밧데리기술에 큰 변화가 없기 때문이죠.

모바일은 "일부러" 적당히 일하는 컴퓨터입니다.


자바스크립트같이 이벤트대응식으로 프로그래밍하는 분야는

사실상 CPU파워를 체감하기가 힘듭니다. 마치 전화중계기처럼

이벤트와 API를 연결하는 과정에 하드한 부분이 있을리도 없으며

이벤트가 발생한 1회성 시점은 왠만해서는 사람이 체감되기는 힘들기 때문이죠.

버튼을 클릭하고 0.01초만에 되던 것이 0.3초에 되어도 사람은 체감하기 힘듭니다.

버튼을 누르는 행동을 했기 때문입니다. 사람이 체감하려면 끊임없이 연속된

과정상에서의 실행속도여야 하거든요.

이벤트대응의 코드는 CPU속도와 관계가 좀 없다고도 할 수 있지요.

반면에 할 수 있는 역할도 매우 한정적이지만요.


아.. 글을 쓰다보니 꽤 길어졌네요.. ㅎ

여튼 CPU는 충분히 빠르지 않다는 것이 제 의견입니다.

그래서 C++이 더욱 중요해지고 있다는 것이죠.

고객의 눈은 훨씬 더 올라갔는데 CPU는 10년째 제자리걸음입니다.

크로미움을 보면 아시겠지만 크롬이 세계적으로 한건을 한

스크립트 고속실행기술도 결국 C++작품입니다.

C++의 최적화기술이 결국 상품의 승패를 결정할 겁니다.

그리고 여러분께 포르쉐를 선물하겠죠..


-9
2
  • 댓글 28

  • fender
    23k
    2020-08-18 07:26:45 작성 2020-08-18 09:11:27 수정됨

    소프트웨어 시스템의 성능을 언어의 실행 속도만으로 이해하는 건 초보 개발자들에게 매우 흔한 착각이긴 합니다.

    보통 실제 시스템을 정량적으로 프로파일링 하면서 최적화를 해보거나 스케일 업과 스케일 아웃의 차이 같은 걸 배우고 경험을 쌓아야 감이 생기는 주제이긴 합니다.

    그런 경험이나 공부 없이 "내가 쓰는 언어는 니가 쓰는 것보다 50%나 빠른데 그 딴 후진 건 왜 씀? 복잡해서 못 배우는 거임? ㅋㅋ" 이 수준에 갇혀 있어서는 왜 소프트웨어 분야가 지금 처럼 발전해왔는지 이해하기 어렵습니다.

    개발 공부나 기술 동향 파악을 거의 죄악시 하는 분이니 "자바 스크립트 같이 실행 성능이 느린 언어의 역할은 매우 제한적이다" 같이 현실과 완전히 동떨어진 믿음을 고수하고 계신 것이겠지만 말입니다.

    생각보다 초보 분들 사이에 흔한 착각이기 때문에 장님이 장님을 이끄는 식으로 이 글을 보고 엉뚱한 편견에 빠질까봐 관련 주제로 썼던 글을 소개합니다:


    왠지 그 때도 이 분이 "가상머신 쓰는 언어를 하면 커리어를 망친다", "가상머신 쓰는 언어는 느려서 해외에서도 모두 걷어내는 추세다" 같은 황당한 주장을 하기에 쓴 글 같은데, 아직도 똑같은 편견에서 못 벗어 난 걸 보면 공부를 안하는 개발자의 한계가 무엇인지 스스로 증명하고 있는 것 같습니다.

  • dongwoo00
    493
    2020-08-18 07:45:07 작성 2020-08-18 07:45:56 수정됨

    영상분석, 이미지프로세싱, 크롤링...

    위에서 언급한 부분을 개발하는 개발자가 전체 개발자 중 몇 %가 될거라고 생각하시나요?

    얼마 안됩니다. 얼마 안되는 그분들에겐 C++가 어울릴거 같기도 합니다. 아니, 어셈블리어는 더 잘 맞을거 같네요.

    그리고 그 외 나머지 대부분의 개발자들은 C++가 어울리지 않을거라는 말이 되기도 하네요

  • fender
    23k
    2020-08-18 07:47:10

    근데 크롤링은 딱히 CPU 인텐시브한 작업이 아니고, 성능만 따지자면 나머지는 GPU로 하는 게 훨 나을 겁니다 ㅎㅎ

  • 머신러닝
    1k
    2020-08-18 07:57:41

    CPU가 충분히 빠르지 않다는 말씀에는 어느 정도 동의합니다. 그래서 GPU를 쓰죠...

    특히 요즘 영상분석에 다 GPU를 이용합니다. GPU가 CPU에 비해서 50~100배 정도 빠르기 때문이죠..


    앞으로 C++ 이런 것이 먹여 살리는게 아니라 인공지능 분야에 더 기회가 있을 것 같네요...

    https://www.youtube.com/watch?v=I7sZVrwM6_Q

    GPT3 모델 한번 보시죠.



  • fender
    23k
    2020-08-18 08:18:01 작성 2020-08-18 09:12:49 수정됨

    갑자기 드는 생각인데 어쩌면 CPU vs GPU의 차이도 왜 성능을 실행 속도만 놓고 따질 수 없는가를 이해하는 데 도움이 되는 예가 될 수 있지 않나 싶습니다.

    GPU가 CPU보다 클락 속도가 100배 쯤 빨라서 그런 차이가 생기는 것이 아니라 특정 성격의 연산을 위해 최적화된 아키텍쳐로 설계되었기 때문이니까요. 서버 시스템의 최적화도 비슷하게 구현 언어의 실행 성능이 중요한 것이 아니라 발생하는 부하와 병목의 성격에 따라 이를 최적화하는 아키텍쳐를 찾는 것이 핵심이라는 점에서 어느 정도 유사성이 있는 것 같습니다.

    여담이지만 머신러닝 같은 분야의 발전을 보면 소프트웨어 분야가 얼마나 빠르게 분화하고 전문화하는지 실감하게 됩니다.

    사실 초보분들은 웹 개발 같은 건 아무나 하는 것이고 머신러닝은 초특급 개발자만 할 수 있다고 착각하는 경우가 흔한데, 난이도를 떠나서 개발 자체에 대한 내용만 따지면 사실 웹 개발 쪽이 머신러닝보다 훨씬 깊이 있고 복잡한 분야입니다.

    머신러닝에서 어려운 건 소프트웨어 설계나 구현이 아니라 모델이나 알고리즘(참고로, 여기서 말하는 '알고리즘'은 백준 문제 같은 것보단 수학에 가까운 내용입니다)을 만드는 것이니까요.

    저수준 논쟁을 하면서 소프트웨어 분야의 발전을 이해 못하고 아직도 무언가 하드웨어에 가까운 게 '근본'이고 그것만 파면 위에 쌓인 건 쉽게 배울 수 있다는 식의 편견을 가진 분들을 자주 보는데, 요즘엔 비슷한 이유로 어쩌면 리팩터링이나 디자인 패턴 같은 소프트웨어 공학적 지식도 더 이상 보편적으로 중요한 기본기라고 보긴 어렵지 않나 하는 생각이 듭니다.

    디자인 패턴만 해도 객체지향을 떠나면 중요도가 떨어지거나 모양이 크게 바뀌고, 머신러닝 같은 분야는 소프트웨어 설계보단 수학 지식이 훨씬 중요하니까요. 요즘엔 '소프트웨어'라는 이름으로 크게 묶이긴 해도, '데이터 과학' 같은 파생 분야도 늘어나고 점점 모든 분야에 공통으로 적용할 수 있는 '근본 지식' 같은 건 큰 의미가 없어지는 방향으로 움직이는 것이 아닌가 싶습니다.

    역시 여담입니다만 생각해보니 머신러닝 처럼 이 분과 안맞는 분야도 없겠군요. 컴파일러 붙잡고 씨름한다고 조금이라도 이해할 수 있는 분야도 아니고 C++을 주력으로 쓰는 분야도 아닌데 다들 어려운 개발 분야라고 생각하고 관심도 많으니 아마 마음이 편하지 않겠군요 ㅎㅎ

  • 머신러닝
    1k
    2020-08-18 08:39:50

    @fender

    역시 여담입니다만 생각해보니 머신러닝 처럼 이 분과 안맞는 분야도 없겠군요. 

    ㅋㅋ 네. 일단 머신러닝 분야에서 공부는 필수기 때문이겠죠...


    최근 조사에 의하면 대기업 절반 이상이 AI를 도입했고 80% 이상이 도입의 성과에 만족했다고 합니다. AI를 도입만 하면 기존 사람들이 맡아서 하던 서비스에서 AI가 더 나은 성과를 보인다는 얘깁니다.

    사실 나머지 기업들도 AI를 도입하고 싶어하나 AI전문 인력이 부족해서 못하고 있는 실정이죠.

    근데 AI인력이야 수요가 있으니 공급이 계속 늘어날 것이고...

    결국 앞으로 거의 모든 기업들이 AI를 도입할 것이라 생각됩니다. 

  • 우헤헤
    333
    2020-08-18 09:47:14

    뭐 이런 멍멍이같은 소리를 부끄럽도 없이 써재꼈지.

    클럭이  cpu 순 성능이였으면  동일 클럭 cpu는  브랜드와 무관하게 같은 성능을 낸다라는 개같은 논린데.

    https://www.cpubenchmark.net/singleThread.html

  • choju
    1k
    2020-08-18 10:59:23

    본문에 나와있듯 절차적인 수행에 있어서 시피유의 속도가 부족하다는 말씀이신것 같아요.

    동의합니다.

    사실 우리 입장에서는 빠르면 빠를 수록 좋긴한대 현실은 느리니까요.. 우리가 느린 시피유에 맞추기위해 씨플플이 필요하다는 주장이신것 같아요.

    그렇지만, 굳이 vm기반언어를 언급하면서 "다른" 비교군을 둘 필요까지도 없는것 같기두하내요.

    뭐.. 효과적인 설명을 위함일 수도 있을거라는 생각은 하지만요.. 밑에서 팬더님이 부연링크도 붙여주셨으니.. 많은 정보취합하셔서 자신만의 정보를 만드는게 중요하겠내욤.

  • 꽃중년보넥스
    -1k
    2020-08-18 11:52:49

    넹~ 다른 대안이야 있겠지만

    CPU의 직렬적 알고리즘 구현속도는 빠르지 않다.

    그런데 GPU아닌 CPU만 할 수 있는 직렬적 알고리즘이

    꽤 있다는 것.

    -1
  • 돈까스
    5k
    2020-08-18 12:44:08 작성 2020-08-18 12:44:22 수정됨

    https://okky.kr/article/472958

    우리 시간 낭비 하지 맙시다.


  • 컴퓨터연구소
    245
    2020-08-19 08:34:50
    사실 컴퓨터공학에서 cpu는 지금도느리다라는건 그게 c++이든 자바든 어셈블리든 느리다는것인데.. c++로 하면 만족하는속도가나온다는 그런차원이아닌데.. 큰 솔루션회사야 더성능을쥐어짜기위한것이고 안그런 대부분은 생산성을본것이지 c++이면 속도가만족하기때문에 쓴다고착각하시는글이네요  물론개발자입장에서 c++커리어가좋다고쓰시면모를까 cpu가느려서c++이주목받는다는건좀....  학부생마인드..
  • 꽃중년보넥스
    -1k
    2020-08-19 09:30:07

    VM으로 바이트코드를 실행하는 속도보다

    네이티브 응용프로그램의 속도가 8000배 빠릅니다.

    네이티브 응용프로그램은 뭘로 만들죠?

    C++등(델파이/오브젝티브씨)으로 만들죠.


    VM계열이 느리지 않은 것처럼 느껴지는 것은

    컴포넌트 생성, 이벤트처리를 주로 하기 때문이고

    하드캐리한 부분은 C++로 만들어진 VM이 해소해

    주기 때문입니다. 하지만 VM언어로 이미지프로세싱이나

    동영상프로세싱을 억지로 해보세요. 8000배 느립니다.


    만약 CPU가 충분히 빠르다면 8000배 느려도 좋겠지만

    그렇게 믿고 싶은거지 실제로는 한계점에 도달했어요.

    고객의 기대치만 나날이 올라갑니다.

    그래서 WASM이 나온 건지도 모르죠..

    -3
  • fender
    23k
    2020-08-19 17:15:16

    8000배라니... -ㅅ- 생각나는 숫자 막 뱉는 건가...;

    노파심에서 이야기하지만 저 분 전부터 VM에 대해선 터무니 없는 거짓 정보 유포하는 사람이니 혹시 잘 모르는 분들은 저런 글 그냥 믿지 말고 검색이라도 해서 검증을 해보시는 걸 추천 드립니다.

  • 꽃중년보넥스
    -1k
    2020-08-19 19:01:33

    테스트해 본겁니다.

    -1
  • 꽃중년보넥스
    -1k
    2020-08-19 19:27:17
    -1
  • 꽃중년보넥스
    -1k
    2020-08-20 00:14:44

    저 변명으로 가득한 링크는 뭔가요? Java 약파는 링크인가요? ㅎ

    "삼각함수등 일부에서는 C가 훨씬 좋습니다".. 훨씬? 몇배라고 숫자를 적어야지 훨씬? ㅋㅋ


    확실히 언어의 속도가 드러나는 분야가 있습니다.

    이미지 필터링이나 문서 파싱같은 것인데요.

    제가 실시한 테스트결과( https://okky.kr/article/444082 )는 RGB를 YUV420으로

    전환하면서 쉐이더를 타기 위한 사전 블랜딩작업을 한 것인데요. 이미지프로세싱이죠.

    화소가 4300x3400이었습니다. 픽셀이 1462만개 들어갑니다.


    Java로 2중 for문을 1462만회 돌면서 GetPixel함수를 호출하여 RGB값을 추출하여

    Java언어로 수학적 연산을 하여 비트맵타입의 메모리버퍼에 그 결과를 적재하는 일이지요.

    결과는 80초가 걸렸습니다. Java는 1초에 18만2750개의 점을 처리했구요.

    이 결과는 1ms에 183개의 점을 처리했다는 뜻입니다. 대단한 것 같나요? ㅎ


    그러나 C++은 이 모든 공정이 10ms에 끝납니다. (함수콜은 최적화되어 전부 사라짐.)

    jpg를 디코딩하여 레스터라이징하고 1462만개의 픽셀에 수학연산을 가하는 시간이

    10ms라는 것이죠. 그리고 투덜거립니다. 왜 이렇게 느려?!

    왜냐면 60프레임이 나와야 하는 응용프로그램은 한 프레임을 17ms에 그려야 하는데

    저 작업에 10ms나 써버렸으니까요.


    80초는 80000ms입니다.

    그래서 제가 측정한 분야에서 C++과 Java의 차이는 8000배라고 말하는 것입니다.

    Java개발자(저도 사실 Java개발자이기도 합니다)에게 이런 문제에 대하여 말해보면

    그런 용도로 사용하지 말라고 합니다.

    그러나 어쩌겠습니까? Java의 VM코어에서 제공해 주지 않는 기능이며

    늦든 빠르든 Java로도 가능한 연산이거든요.


    -2
  • fender
    23k
    2020-08-20 02:52:24 작성 2020-08-20 02:55:25 수정됨

    C/C++과 자바에 대한 극단적인 편견을 가진 님이 어떤 조건으로 실험했는지 밝히지도 않는 케이스 하나에 비하면 제가 링크한 페이지에 소개된 몇몇 벤치마크는 백 만 배는 더 신뢰할 수 있는 자료입니다.

    각주에 논문등 원 출처 다 링크되어 있는데 영어도 못해서 안 읽어 놓고 숫자가 없다고 버럭하면 안 쪽팔린지... JIT가 뭔지는 알아요? ㅎㅎ

    그리고 저 페이지 링크 말고도 자바와 네이티브 언어의 벤치 마크를 포함하는 기사, 논문은 수도 없이 많습니다. 벤치마크 종류에 따라 자바가 살짝 빠른 정도부터 최악은 10배 가량 차이를 보이는 경우가 있고, 보통은 수십 퍼센트 정도 선에서 자바가 느린 걸로 나오는 게 일반적입니다.

    그리고 그 정도 속도면 거의 대부분의 분야에서 성능에 전혀 문제가 없는 수준입니다, 그러니 님의 상상 속 세계와는 다르게 자바, C#, 파이썬, JS 등의 언어가 그렇게 널리 쓰이게 된 것이죠.

    참고로 전 님 생각을 바꾸기 위해 이런 글을 쓰는 게 아닙니다. 이미 님의 맹신과 편협함은 누구의 어떤 도움으로도 치유될 수 없는 성격임을 님 스스로 증명했기 때문에, 그런 시간 낭비할 생각은 없습니다.

    제가 굳이 이런 덧글을 다는 이유는 혹시라도 님 때문에 입문자 분들이 잘못된 정보를 사실로 착각하거나 님과 비슷한 편견에 빠질까 걱정되기 때문일 뿐입니다.

  • 꽃중년보넥스
    -1k
    2020-08-20 10:36:25

    함수콜 속도를 비교하는건 의미가 없어요.

    C++은 함수콜이 최적화해서 날아갑니다.

    for를 전개해 버리기도 하구요.

    자바는 정직하게 실행합니다.

    최적화같은거 없어요.

    왜냐구요?


    C++은 소스코드가 수십만줄 정도되면

    최적화전개에 수십분의 시간이 걸리기도 합니다.

    그런데 자바는 전개할 수가 없어요.

    디컴파일해서 원본소스를 추출해야 하는게 기조라서.

    그리고 런타임에 수십분 기다릴 건가요? 그것도 안되죠.


    C++진영은 수십년간 쌓인 최적화노하우가 있어서

    빠른겁니다. 정직하게 돌리면 10ms가 아니라 수십초가

    걸릴 겁니다.


    그런데 자바진영에 속도를 물어보면 뭐라고 그러겠어요?

    함수콜시간, 한줄짜리 산술시간 측정하겠죠.

    그걸 펜더님같은 중급개발자는 신주단지 모시듯 하면서

    혹 어마어마한 결과차이가 보이는 일을 누군가 말하면

    "자바는 그렇게 사용하시는 것이 아니예요~"

    그러겠지요..ㅎ

    -1
  • fender
    23k
    2020-08-20 13:38:12 작성 2020-08-20 13:42:28 수정됨
    최적화전개에 수십분의 시간이 걸리기도 합니다. 그런데 자바는 전개할 수가 없어요.

    'JIT'라고 키워드 힌트를 줘도 공부는 죽어라 안하고 계속 헛소리/거짓 정보 유포하는 저 당당함이란...

    뭐, 님이 앞으로 또 입문자들 현혹하는 글 쓰면 그냥 저 사람 아는 건 쥐뿔도 없으면서 이런 헛소리를 당당하게 한다 하고 소개할 어록이 점점 늘어나는 건 좋은 일이긴 합니다.


  • 꽃중년보넥스
    -1k
    2020-08-20 14:48:48

    자바 컴파일이 처음 나왔을때

    제가 자바개발자였었습니다. exe도 직접 만들어 봤어요 ㅎ

    한때 별명이 자바의 신이었다니까요? ㅋㅋ


    그러나 VM과 네이티브응용프로그램의

    차이를 설명하는 것이지 C++, Java로 할 수 있는

    모든 것을 논하자는 것이 아니죠.


    VM방식의 자바와 응용프로그램방식의 C++간의

    차이를 설명하는 맥락입니다.

    박박 우겨보자란게 아니고~ㅎㅎ

    -1
  • 꽃중년보넥스
    -1k
    2020-08-20 14:51:48

    과거에 제가 EA다닐때 해외 스튜디오중 한군데에서는

    자바로 원개발하고 컨버팅툴을 이용하여 C++로

    소스컨버팅하여 빌드하는 방식으로 개발합니다.

    그럼 이건 C++인가요? 자바인가요? ㅎㅎ

    여튼 물타기 고수셔~ㅋㅋ

    -1
  • 꽃중년보넥스
    -1k
    2020-08-20 15:35:15 작성 2020-08-20 15:35:37 수정됨

    Java도 JIT컴파일해서 응용프로그램 만들면

    성능이 좋아진다는 소리는

    스스로 VM을 부정하는 자살골..ㅎ


    -1
  • 지붕뚫고높이차
    1k
    2020-08-21 08:15:58 작성 2020-08-21 08:52:03 수정됨
    재밌는 내용이네요.

    파이프라인 해저드라는 오래된 문제가 있습니다.

    파이프라인 기술은
    하나의 코어만 있는(하나의 ALU 만 사용) cpu에서
    한개의 명령어 실행주기를 쪼개
    여러개 명령어를 동시에 실행하기 위한 기술인데요.

    파이프라인 해저드는 구조,데이터,제어 문제로
    명령어 실행이 잠시 멈추는 스톨이나
    미리 실행한 명령어 결과를 버리는
    cpu 성능이 저하 되는 결과가 발생합니다.

    해저드를 해결할 방법은 없습니다.
    cpu가 사용할 자원은 한정되어 있고
    데이터 보호를 위한 락킹은 비용이 많이 듭니다.
    그리고 앞으로 실행될 명령어는 사람은 알수 없기 때문이죠.

    해저드를 공격한
    멜트다운 이나 스펙터 보안 취약점이 발생해도
    쉽게 고치지 못하는 것도 같은 이유입니다.

    다시 본론으로 들어와
    성능이 중요한 이미지 프로세싱같은 기능은
    파이프라인 해저드 제어가 가능한
    c 나 c++ 같은 언어 즉 기계어 수준까지 재구성 해서

    cpu 성능저하 근본 문제인
    파이프라인 해저드를 회피할 수 있는
    언어를 사용하는게 맞습니다.

    분기문이 문제라기 보다는
    파이프라인 해저드가 근본 문제인 것 같아 적어봤습니다.

    대부분 언어는 수행 성능을 위해
    병행 병렬 처리 기능을 제공합니다.
    쉽게 사용할 수 있도록 추상화도 되어 있구요.

    하지만  추상화는 시간이라는 비용이 필요합니다.

    시간이라는 비용이 체감할 정도면 c++을 사용하는게 맞고
    아니라면 java 를 사용하는게 다른 비용을 줄일 수 있겠죠.

    글쓴분 내용이 맞는 것 같은데
    평소 어그로를 많이 끌어
    비추가 많은 건가요? ㅎㅎㅎ


  • 꽃중년보넥스
    -1k
    2020-08-21 10:21:18

    제가 설명을 잘 못해서 그래요 ㅎㅎ

    설명 참 잘하시네요~^^

    -1
  • fender
    23k
    2020-08-21 16:10:43 작성 2020-08-21 16:14:18 수정됨

    지붕뚫고높이차 // 실행 성능이 크리티컬한 분야에서 C나 C++ 같은 저수준 언어를 쓰는 게 유리하다는 걸 부정하는 사람은 아무도 없습니다.

    그런데 그 논리를 확장해서 성능이 중요하니 C++이 최고라고 주장하면, 아시다시피 그건 매우 나이브하고 무리한 주장이 됩니다.

    그리고 로보넥스 저 사람은 지속적으로 같은 취지에서 "VM 언어를 쓰면 커리어를 망친다", "해외에선 VM 언어는 느려서 걷어내는 추세다" 같은 황당한 주장을 했고, 이 글타래에서도 다수의 객관적인 벤치 마크 자료를 제시 했음에도 C++이 자바보다 8,000 배나 빠르다는 식의 근거없는 이야기를 반복하고 있습니다.

    CPU의 성능을 쥐어짜야 하는 영역에서 어떻게 C++이 다른 언어에 비해 강점이 있는지 같은 걸 설명하는 글을 쓴다면 추천을 하면 했지 아무도 뭐라 하지 않을 겁니다.

    기술 공부에 대해 담을 쌓은 사람 - 다른 글 보시면 아시겠지만, 개발 공부나 기술 동향 파악 자체를 거의 죄악시 합니다 - 이 "아몰라 아무튼 내가 쓰는 게 무조건 최고임"만 반복하니 어그로 취급을 받는 것 뿐입니다.

  • 꽃중년보넥스
    -1k
    2020-08-21 16:22:57

    기술공부에 대해 담을 쌓은 사람이라는 표현보다.

    다른 이들이 남의 기술 공부할 시간에

    자기 기술의 영역을 닦아나가는 기술자라고 표현해 주세요~ㅋ


    -3
  • Frudy
    7k
    2020-08-23 09:34:18

    어...음...어 

    지금은 무슨내용인지는 하나도모르겠지만

    스크랩은 해둘게요. 

    중요할거같은 내용이 댓글에 있어서요

  • 로그인을 하시면 댓글을 등록할 수 있습니다.