Dmitry Fedoseev : CPU에 대해 이야기하십시오. 카드는 간단할 수 있지만 중앙 프로세서는 여전히 존재합니다. 3000개의 코어가 있는 CPU는 어디에 있습니까?
논쟁의 요점이 이해가 되지 않습니다. 코어 수를 늘리는 과정에서 프로세서가 개발되기 시작했다고 말씀하셨습니다. 나는 동의하고 3000개의 코어가 있는 GPU의 예를 제시했습니다. 같은 수의 코어를 가진 CPU가 왜 없는지 알고 싶으십니까? 정확히 이해하셨나요? GPU가 마음에 들지 않는 이유는 무엇입니까? CPU는 둘 중 하나일 수도 있습니다. 글쎄, 많은 코어가 필요하다면 해당 GPU와 프로그램을 구입하십시오. 그러나 많은 코어가 필요하지 않다면 논쟁은 아무 소용이 없습니다. 내 관점은 멀티 코어 경로를 따라 프로세서 개발이 2004-2005년에 여전히 시작되었다는 것입니다. 따라서 무어의 법칙이 끝난 후에는 새롭지 않을 것입니다. 지금 코어가 필요하지 않다면 2020년 이후에도 코어가 필요하지 않을 것입니다.
Vladimir : 논쟁의 요점이 이해가 되지 않습니다. 코어 수를 늘리는 과정에서 프로세서가 개발되기 시작했다고 말씀하셨습니다. 나는 동의하고 3000개의 코어가 있는 GPU의 예를 제시했습니다. 같은 수의 코어를 가진 CPU가 왜 없는지 알고 싶으십니까? 정확히 이해하셨나요? GPU가 마음에 들지 않는 이유는 무엇입니까? CPU는 둘 중 하나일 수도 있습니다. 글쎄, 많은 코어가 필요하다면 해당 GPU와 프로그램을 구입하십시오. 그러나 많은 코어가 필요하지 않다면 논쟁은 아무 소용이 없습니다. 내 관점은 멀티 코어 경로를 따라 프로세서 개발이 2004-2005년에 여전히 시작되었다는 것입니다. 따라서 무어의 법칙이 끝난 후에는 새롭지 않을 것입니다. 지금 코어가 필요하지 않다면 2020년 이후에도 코어가 필요하지 않을 것입니다.
그리고 병렬 CPU 코어를 위한 프로그램을 작성하는 것이 GPU보다 쉽다고? 문제는 동일합니다. 프로그래머는 머리를 깨고 프로그램의 어느 부분을 병렬화할 수 있는지 결정하고 특수 병렬화 코드를 작성하는 등의 작업을 해야 합니다. 대부분의 프로그래머는 이것으로 고통받지 않으며 군더더기 없는 단일 코어 프로그램을 작성합니다. 여기서 문제가 무엇입니까? 코어 또는 멀티 코어를 사용하는 프로그램이 부족합니까? 마지막 것 같아요. 3000코어 CPU를 줘도 3000코어와 4코어 프로그램 작성 난이도 차이가 없기 때문에 싱글코어 프로그램을 계속 쓰게 됩니다. 병렬화할 수 있는 코드 조각을 자동으로 인식할 수 있는 새 컴파일러가 필요합니다. 그러나 다시 말하지만 그러한 컴파일러를 만드는 과정은 하드웨어에 의존하지 않고 프로그래머가 그러한 컴파일러를 작성하려는 욕구에 달려 있습니다. 이 쓰레드 전반에 걸쳐 나는 반도체 기술이 트랜지스터의 다운사이징과 소비전력의 끝을 맞이하고 있기 때문에 2020년 이후에 새로운 하드웨어를 만드는 능력이 줄어들고 있다고 주장하고 있습니다. 새로운 재료와 트랜지스터는 아직 개발 중입니다. 인텔은 2016년에 Knight Hill 세대의 10nm 프로세서를 만들려고 시도했으며 이 세대를 2017년 말까지 연기했습니다. 삼성은 또한 앱 프로세서용 10nm 기술에 문제가 있습니다. 이미 10nm 크기에서 트랜지스터는 14nm에 비해 크기와 전력이 약간만 감소합니다. 방열이 큰 문제가 됩니다. 기술의 도약이 필요합니다. 기술 지표 중 하나는 트랜지스터당 가격입니다. 그래서 이 가격은 28nm로 떨어졌고, 그 후 기하급수적으로 성장하기 시작했습니다. 많은 회사들이 가격 때문에 28nm에 정착했습니다. 즉, 10nm 기술과 7nm, 마지막 5nm 기술로의 진행은 발열 문제뿐만 아니라 큰 가격도 동반하게 될 것입니다.
이제 병렬화에는 문제가 없지만 CPU를 사용할 때만 가능합니다. C#에서는 3초 만에 완료됩니다. 오히려 많은 수의 코어가 필요하지 않은 것이 사실입니다. 일반적이고 평균적인 프로그램은 병렬화되지 않습니다. 코어를 많이 만들면 다양한 프로그램을 실행할 수 있다는 유일한 이점이 있지만 이것이 꼭 필요한 것은 아닙니다.
그리고 병렬 CPU 코어를 위한 프로그램을 작성하는 것이 GPU보다 쉽다고? 문제는 동일합니다. 프로그래머는 머리를 깨고 프로그램의 어느 부분을 병렬화할 수 있는지 결정하고 특수 병렬화 코드를 작성하는 등의 작업을 해야 합니다. 대부분의 프로그래머는 이것으로 고통받지 않으며 군더더기 없는 단일 코어 프로그램을 작성합니다. 여기서 문제가 무엇입니까? 코어 또는 멀티 코어를 사용하는 프로그램이 부족합니까? 마지막 것 같아요. 3000코어 CPU를 줘도 3000코어와 4코어 프로그램 작성 난이도 차이가 없기 때문에 싱글코어 프로그램을 계속 쓰게 됩니다. 병렬화할 수 있는 코드 조각을 자동으로 인식할 수 있는 새 컴파일러가 필요합니다. 그러나 다시 말하지만 그러한 컴파일러를 만드는 과정은 하드웨어에 의존하지 않고 프로그래머가 그러한 컴파일러를 작성하려는 욕구에 달려 있습니다.
R에는 설명된 문제가 없습니다.
1. 아마도 계산적으로 복잡한 알고리즘을 위한 프로그램을 작성할 필요가 없을 것입니다. 모든 것이 작성되었으며 계산적으로 복잡한 알고리즘(예: 최적화 또는 부스팅)이 병렬 처리를 허용하는 경우 이는 이미 구현된 것입니다. 그리고 당신은 아무데도 볼 필요가 없습니다. 개발자는 문제의 내용에서 이 내용으로 도구가 선택되고 도구의 모든 것이 최대한 구현됩니다. 도구 선택을 위한 인건비를 줄이기 위한 강력한 도움말 시스템이 있습니다.
2. 예를 들어 루프의 일부를 병렬로 실행해야 하는 경우 병렬 처리를 위한 도구가 있습니다. 그러한 구성의 구문을 설명하고 사용 조건을 설명할 때 머리를 긁적일 필요가 없습니다.
3. 이 프로그램은 이 컴퓨터의 코어뿐만 아니라 주변 컴퓨터도 로드할 수 있습니다. 이것은 즉석 컴퓨터에서 말하자면 구름이 없는 것입니다.
당신이 설명한 문제는 철에서 보편적인 알고리즘 언어를 통해 문제에 도달하지 않는다는 사실에서 발생했습니다. 문제에서 도구 선택에 이르기까지 반대 방향으로 이동하면 하드웨어에 대해 전혀 이야기할 필요가 없을 수도 있습니다.
그러므로 나는 위에서 내가 내린 결론을 반복한다. 이 모든 기가헤르츠는 프로그램 실행의 효율성과 극히 약한 관계를 갖는다. 우리가 지난 15년 동안 기가헤르츠의 증가를 눈치채지 못한 것처럼, 우리는 이 같은 기가헤르츠의 성장이 멈추는 것을 눈치채지 못할 것입니다.
GPU = 그래픽 처리 장치(주로 Nvidia에서 생산)
CPU = 중앙 처리 장치(Intel 또는 AMD에서 제조)
두 프로세서 모두. 명확하지 않습니까? GPU를 카드나 원하는 대로 부르세요. 하지만 최신 모델이 있다면 3000코어 프로세서입니다. 컴퓨터가 있으면 GPU도 있습니다. 문서에서 설치한 모델과 코어 수를 읽으십시오.
우울함은 없고 미래에 대한 두려움이 있습니다. 나와 다른 사람 모두 ...
왜 두려워? 문제가 무엇입니까?
글쎄요, 새로운 컴퓨터는 없을 것입니다. 그래서 어떻게 될까요? 모든 것이 이전과 같을 것이며 이제 더 이상 투명하지 않지만 새로 추가된 모든 리소스를 잡아먹는 반짝이는 인터페이스로 다음 Windows에는 나타나지 않을 것이라고 생각하십시오.
GPU = 그래픽 처리 장치(주로 Nvidia에서 생산)
CPU = 중앙 처리 장치(Intel 또는 AMD에서 제조)
두 프로세서 모두. 명확하지 않습니까? GPU를 카드나 원하는 대로 부르세요. 하지만 최신 모델이 있다면 3000코어 프로세서입니다. 컴퓨터가 있으면 GPU도 있습니다. 문서에서 설치한 모델과 코어 수를 읽으십시오.
CPU에 대해 이야기하십시오. 카드는 간단할 수 있지만 중앙 프로세서는 여전히 존재합니다. 3000개의 코어가 있는 CPU는 어디에 있습니까?
CPU에 대해 이야기하십시오. 카드는 간단할 수 있지만 중앙 프로세서는 여전히 존재합니다. 3000개의 코어가 있는 CPU는 어디에 있습니까?
논쟁의 요점이 이해가 되지 않습니다. 코어 수를 늘리는 과정에서 프로세서가 개발되기 시작했다고 말씀하셨습니다. 나는 동의하고 3000개의 코어가 있는 GPU의 예를 제시했습니다. 같은 수의 코어를 가진 CPU가 왜 없는지 알고 싶으십니까? 정확히 이해하셨나요? GPU가 마음에 들지 않는 이유는 무엇입니까? CPU는 둘 중 하나일 수도 있습니다. 글쎄, 많은 코어가 필요하다면 해당 GPU와 프로그램을 구입하십시오. 그러나 많은 코어가 필요하지 않다면 논쟁은 아무 소용이 없습니다. 내 관점은 멀티 코어 경로를 따라 프로세서 개발이 2004-2005년에 여전히 시작되었다는 것입니다. 따라서 무어의 법칙이 끝난 후에는 새롭지 않을 것입니다. 지금 코어가 필요하지 않다면 2020년 이후에도 코어가 필요하지 않을 것입니다.
편도선 절단에 대한 농담이 생각납니다 ...자가로 ... sn을 통해.
그리고 병렬 CPU 코어를 위한 프로그램을 작성하는 것이 GPU보다 쉽다고? 문제는 동일합니다. 프로그래머는 머리를 깨고 프로그램의 어느 부분을 병렬화할 수 있는지 결정하고 특수 병렬화 코드를 작성하는 등의 작업을 해야 합니다. 대부분의 프로그래머는 이것으로 고통받지 않으며 군더더기 없는 단일 코어 프로그램을 작성합니다. 여기서 문제가 무엇입니까? 코어 또는 멀티 코어를 사용하는 프로그램이 부족합니까? 마지막 것 같아요. 3000코어 CPU를 줘도 3000코어와 4코어 프로그램 작성 난이도 차이가 없기 때문에 싱글코어 프로그램을 계속 쓰게 됩니다. 병렬화할 수 있는 코드 조각을 자동으로 인식할 수 있는 새 컴파일러가 필요합니다. 그러나 다시 말하지만 그러한 컴파일러를 만드는 과정은 하드웨어에 의존하지 않고 프로그래머가 그러한 컴파일러를 작성하려는 욕구에 달려 있습니다. 이 쓰레드 전반에 걸쳐 나는 반도체 기술이 트랜지스터의 다운사이징과 소비전력의 끝을 맞이하고 있기 때문에 2020년 이후에 새로운 하드웨어를 만드는 능력이 줄어들고 있다고 주장하고 있습니다. 새로운 재료와 트랜지스터는 아직 개발 중입니다. 인텔은 2016년에 Knight Hill 세대의 10nm 프로세서를 만들려고 시도했으며 이 세대를 2017년 말까지 연기했습니다. 삼성은 또한 앱 프로세서용 10nm 기술에 문제가 있습니다. 이미 10nm 크기에서 트랜지스터는 14nm에 비해 크기와 전력이 약간만 감소합니다. 방열이 큰 문제가 됩니다. 기술의 도약이 필요합니다. 기술 지표 중 하나는 트랜지스터당 가격입니다. 그래서 이 가격은 28nm로 떨어졌고, 그 후 기하급수적으로 성장하기 시작했습니다. 많은 회사들이 가격 때문에 28nm에 정착했습니다. 즉, 10nm 기술과 7nm, 마지막 5nm 기술로의 진행은 발열 문제뿐만 아니라 큰 가격도 동반하게 될 것입니다.
그리고 병렬 CPU 코어용 프로그램을 작성하는 것이 GPU보다 쉽다고?
GPU 아래에서 효과적인 프로그램을 작성하는 것은 정말 매우 어렵습니다.
사실, 장치 간, 장치와 사람 간의 상호 작용 측면에서 아직 미개척 영역이 있습니다.
클라우드 영역이 있습니다. 모든 사람과 모든 것을 그 안에 채우고 탈중앙화합니다.
일반적으로 지능형 비서 및 장치 영역이 있습니다.
증강현실과 가상현실의 영역이 있다
요컨대 , 경기 침체가 없을 것이며 새로운 발전 방법을 모색하게 될 것은 바로 무어의 법칙 때문입니다 . 경기 침체는 다른 이유가 될 것입니다
그리고 병렬 CPU 코어를 위한 프로그램을 작성하는 것이 GPU보다 쉽다고? 문제는 동일합니다. 프로그래머는 머리를 깨고 프로그램의 어느 부분을 병렬화할 수 있는지 결정하고 특수 병렬화 코드를 작성하는 등의 작업을 해야 합니다. 대부분의 프로그래머는 이것으로 고통받지 않으며 군더더기 없는 단일 코어 프로그램을 작성합니다. 여기서 문제가 무엇입니까? 코어 또는 멀티 코어를 사용하는 프로그램이 부족합니까? 마지막 것 같아요. 3000코어 CPU를 줘도 3000코어와 4코어 프로그램 작성 난이도 차이가 없기 때문에 싱글코어 프로그램을 계속 쓰게 됩니다. 병렬화할 수 있는 코드 조각을 자동으로 인식할 수 있는 새 컴파일러가 필요합니다. 그러나 다시 말하지만 그러한 컴파일러를 만드는 과정은 하드웨어에 의존하지 않고 프로그래머가 그러한 컴파일러를 작성하려는 욕구에 달려 있습니다.
R에는 설명된 문제가 없습니다.
1. 아마도 계산적으로 복잡한 알고리즘을 위한 프로그램을 작성할 필요가 없을 것입니다. 모든 것이 작성되었으며 계산적으로 복잡한 알고리즘(예: 최적화 또는 부스팅)이 병렬 처리를 허용하는 경우 이는 이미 구현된 것입니다. 그리고 당신은 아무데도 볼 필요가 없습니다. 개발자는 문제의 내용에서 이 내용으로 도구가 선택되고 도구의 모든 것이 최대한 구현됩니다. 도구 선택을 위한 인건비를 줄이기 위한 강력한 도움말 시스템이 있습니다.
2. 예를 들어 루프의 일부를 병렬로 실행해야 하는 경우 병렬 처리를 위한 도구가 있습니다. 그러한 구성의 구문을 설명하고 사용 조건을 설명할 때 머리를 긁적일 필요가 없습니다.
3. 이 프로그램은 이 컴퓨터의 코어뿐만 아니라 주변 컴퓨터도 로드할 수 있습니다. 이것은 즉석 컴퓨터에서 말하자면 구름이 없는 것입니다.
당신이 설명한 문제는 철에서 보편적인 알고리즘 언어를 통해 문제에 도달하지 않는다는 사실에서 발생했습니다. 문제에서 도구 선택에 이르기까지 반대 방향으로 이동하면 하드웨어에 대해 전혀 이야기할 필요가 없을 수도 있습니다.
그러므로 나는 위에서 내가 내린 결론을 반복한다. 이 모든 기가헤르츠는 프로그램 실행의 효율성과 극히 약한 관계를 갖는다. 우리가 지난 15년 동안 기가헤르츠의 증가를 눈치채지 못한 것처럼, 우리는 이 같은 기가헤르츠의 성장이 멈추는 것을 눈치채지 못할 것입니다.