전력은 어디에나 존재하는 문제이며 시스템 전체를 고려하지 않고 시스템의 에너지 소비를 최적화하는 것은 불가능합니다. 하드웨어 구현 최적화에 엄청난 발전이 이루어졌지만 더 이상 그것만으로는 충분하지 않습니다. 전체 시스템을 최적화해야 합니다.

여기에는 광범위한 의미가 있으며 그 중 일부는 도메인별 컴퓨팅을 향한 길을 주도하고 있습니다. 왼쪽으로 이동하는 것도 중요한 역할을 하지만 더 중요한 것은 정의된 작업에 대한 총 에너지 소비량에서 역할을 하는 모든 당사자가 해당 목표를 달성하기 위해 협력해야 한다는 의미입니다.

에너지는 빠르게 최우선 고려 사항이 되고 있습니다. "에너지 효율성이 모든 컴퓨팅 영역에서 중요한 관심사가 되면서 설계자들은 하드웨어와 소프트웨어 설계 모두에 대한 알고리즘의 에너지 비용을 고려해야 한다는 요청을 받는 경우가 많습니다."라고 Guillaume Boillet 제품 관리 및 전략 마케팅 담당 수석 이사는 말합니다. 동맥. “연산 효율성(속도, 처리량, 대기 시간)만을 위한 최적화에서 에너지 효율성(작업당 줄) 최적화로 초점이 옮겨가고 있습니다. 이를 위해서는 메모리 액세스 수, 계산의 병렬성, 특정 작업에 대해 보다 에너지 효율적인 계산을 제공할 수 있는 특수 하드웨어 가속기 활용 등의 요소를 고려해야 합니다."

이는 하드웨어 구현에서 하드웨어와 소프트웨어 모두의 아키텍처 분석으로 초점을 이동시킵니다. EDA 그룹의 제품 관리 이사인 William Ruby는 "설계 흐름의 후반 단계에서는 최적화 기회가 줄어듭니다."라고 말합니다. Synopsys. “자동 최적화를 위한 더 많은 기회가 있을 수 있지만 개선 비율은 더 낮습니다. 잠재적 절감 곡선을 고려할 때(그림 1 참조) 아키텍처에서 승인까지의 곡선은 매끄럽지 않습니다. 합성에는 변곡점이 있습니다. 디자인이 구현에 매핑되기 전에는 더 많은 자유도가 있지만 이 변곡점 이후에는 상황이 급격히 떨어집니다.”

그림 1: 설계 단계 중 절전 기회. 출처 : Synopsys

가장 큰 장벽은 변곡점 이전에는 전력이 활동에 의존하게 되어 자동 최적화가 훨씬 더 어려워진다는 것입니다. "RTL 개발 중에 동적 벡터 기반 검사를 사용하여 낭비를 발견하고 논리 재구성, 클럭 게이팅, 연산자 게이팅 및 기타 기술을 수행하여 이를 줄일 수 있습니다."라고 수석 제품 관리자인 Qazi Ahmed는 말합니다. 지멘스 EDA. “전력은 사용 사례에 민감하며 가능한 모든 시나리오를 포괄할 수 있도록 실제 소프트웨어 기반 워크로드로 프로파일링해야 한다는 점을 이해하는 것도 중요합니다. 이는 전력 엔벨로프가 IP 수준에서 합성 벡터 기반 분석이 보여줄 수 있는 것과 완전히 다를 수 있는 전체 SoC의 맥락에서 특히 그렇습니다.”

Synopsys의 가상 프로토타이핑 담당 수석 엔지니어인 Tim Kogel은 “더 많은 사전 계획, 프로파일링 및 최적화가 필요할 것입니다.”라고 말합니다.

Kogel은 해결해야 할 다양한 수준을 다음과 같이 지적했습니다.

• 매크로 아키텍처 수준에서 고가의 트레이드오프 분석 및 전용 처리 요소 선택을 위한 것입니다.
• 마이크로 아키텍처 수준에서 대상 애플리케이션에 대한 명령 세트 및 실행 단위를 최적화합니다.
• 알고리즘 수준에서는 계산 효율성과 메모리 액세스를 위한 알고리즘을 선택하고 최적화합니다.
• 소프트웨어 수준에서 전력 및 에너지에 맞게 소프트웨어를 최적화하는 방법에 대한 피드백을 개발자에게 제공합니다.

“이를 위해서는 하드웨어 및 소프트웨어 구현을 최적화할 수 있는 데이터를 생성하기 위한 가상 프로토타입 제작 및 소프트웨어 개발을 위한 전력 및 에너지 인식 도구가 필요합니다.”라고 그는 말했습니다.

소프트웨어 매핑
소프트웨어에 무엇이 포함되어야 하는지 결정하는 것은 초기 작업입니다. "CPU 부담을 덜어주기 위해 DSP 코어를 갖고 싶나요?" Synopsys의 Ruby에게 묻습니다. “이것이 내 전력 소비에 어떤 영향을 미치나요? 하드웨어 가속기를 구현하고 싶은가요, 아니면 소프트웨어에서 이러한 모든 기능을 수행하고 싶은가요? CPU에서 실행되는 소프트웨어의 에너지 비용은 0이 아닙니다.”

시스템이 점점 더 소프트웨어에 의해 정의됨에 따라 에너지에 대한 고려가 시작되어야 하는 곳이 바로 여기입니다. "소프트웨어는 에너지를 절약하고 성능을 향상시키는 핵심 요소입니다."라고 수석 CPU 설계자인 Vincent Risson은 말합니다. 팔. “컴퓨팅 집약적인 애플리케이션은 애플리케이션 최적화를 통해 상당한 이점을 얻는 경우가 많습니다. 이는 고도로 조정된 라이브러리 측면에서 정적일 수도 있고 가장 최적의 처리 엔진을 대상으로 컴퓨팅을 허용하는 동적 프레임워크일 수도 있습니다. 예를 들어, 모바일 장치는 공통 ISA 및 구성을 준수하면서 다양한 컴퓨팅 성능을 애플리케이션 프로세서에 제공하는 CPU 시스템 아키텍처로 표준화되었습니다. 이를 통해 애플리케이션을 효율성에 가장 적합한 프로세서로 동적으로 마이그레이션할 수 있습니다. 소프트웨어와 이기종 하드웨어의 결합을 통해 제공되는 내성과 다양성을 제공하는 메커니즘은 미래에 효율성을 향상시킬 수 있는 기회를 제공할 것입니다.”

소프트웨어가 실행할 수 있는 프로세서 클래스는 두 개 이상인 경우가 많습니다. Intel의 클라이언트 SoC 아키텍처 담당 설계 엔지니어링 그룹 CTO이자 동료인 Jeff Wilcox는 "우리는 현재 보고 있는 워크로드 유형에 따라 특정 애플리케이션을 실행할 위치를 선택할 수 있습니다."라고 말합니다. “더 작은 코어의 요구 사항을 초과하면 더 큰 코어가 작동될 수 있습니다. 가장 전력 효율적으로 실행되어야 하는 위치를 파악하기 위한 원격 측정 및 작업 부하 특성화가 있습니다. 현재 우리가 보고 있는 많은 작업 부하가 다릅니다. 동일한 워크로드에서 작업하는 대칭 에이전트라도 서로 간에 종속성이 있습니다. 점점 더 많은 워크로드에는 GPU, NPU, IPU를 사용할 수 있고 이러한 유형의 워크로드가 CPU와 협력하는 비대칭 에이전트가 필요합니다. 최적화하기가 훨씬 더 어렵습니다. 우리는 성능과 전력 문제를 이해할 수 있는 지점에 도달했지만, 이를 완전히 소화하고 최적화하는 방법을 실제로 이해하기 위한 도구를 계속 구축하고 있습니다."

여기서 어려운 점은 워크로드 아키텍처가 하드웨어 아키텍처에 따라 달라질 수 있다는 것입니다. Untether AI의 하드웨어 부사장인 Renxin Xia는 "AI 분야에는 많은 발전이 있으며 중요한 것은 모델의 크기만이 아닙니다."라고 말합니다. “모델이 어떻게 구성되는지, 그리고 에너지 효율적인 방식으로 구성되는지도 똑같이 중요합니다. 이는 아키텍처에 따라 다르기 때문에 대답하기가 더 어렵습니다. GPU에서 실행되는 알고리즘의 에너지 비용은 컴퓨팅 아키텍처의 메모리에서 실행되는 알고리즘의 에너지 비용과 매우 다를 수 있습니다.”

소프트웨어에 집중
일반적인 합의는 하드웨어-소프트웨어 협력이 강화되지 않으면 이 중 어느 것도 불가능하다는 것입니다. Intel 데이터 센터 부서의 수석 연구원인 Sailesh Kottapalli는 "이러한 단계적 기능 개선을 위해서는 하드웨어-소프트웨어 공동 개발이 필요합니다."라고 말합니다. “하드웨어에서 투명하게 수행하려는 노력은 한계에 도달했습니다. AI에서 무슨 일이 일어나고 있는지 살펴보세요. 하드웨어가 유일한 요소라면 우리가 보고 있는 엄청난 발전을 볼 수 없을 것입니다. 그 중 많은 부분이 알고리즘 개선입니다. 소프트웨어 알고리즘을 사용하면 경로 길이를 줄이면 더 적은 명령 수와 소프트웨어 작업 감소로 동일한 결과를 얻을 수 있습니다. 때로는 이에 대한 명확성을 얻을 때 해당 알고리즘에 대한 새로운 최적의 명령 세트, 새로운 마이크로 아키텍처가 있음을 파악한 다음 하드웨어에서 이를 더욱 최적화할 수 있습니다."

소프트웨어 개발 흐름에 큰 변화가 필요합니다. Synopsys의 Kogel은 “과거에는 아키텍처와 소프트웨어 흐름이 생산성을 위해 최적화되었습니다. 즉, 가장 빠르고 저렴한 소프트웨어 도구를 사용하여 고급 언어로 프로그래밍된 범용 프로세서를 의미합니다.”라고 말합니다. “일반적인 방향은 최대한 많은 유연성과 생산성을 제공하고 꼭 필요한 만큼만 최적화하는 것이었습니다. 이는 필요한 만큼만 유연성을 제공하도록 전환되어야 하며, 그렇지 않으면 전용 구현을 사용해야 합니다.”

많은 소프트웨어 기능에서 메모리 액세스는 전력을 가장 많이 소비하는 부분입니다. Synopsys의 Ruby는 “소프트웨어 기능은 다양한 방식으로 구현될 수 있으며, 그 결과 전력 및 에너지 프로필이 다른 다양한 명령 스트림이 생성됩니다.”라고 말합니다. “메모리 액세스 명령에 가중치를 부여하거나 더 많은 비용을 할당해야 합니다. 사물을 모델링하는 방법에 주의해야 합니다. 단지 CPU일지라도 시스템 맥락에서 에너지 비용을 모델링해야 합니다.”

앞으로는 결과의 정확성도 최적화에 도움이 될 수 있는 요소가 될 수 있습니다. Arteris의 Boillet는 “사용 가능한 하드웨어 리소스를 더 잘 활용하도록 소프트웨어를 최적화하면 상당한 전력 절감 효과를 얻을 수 있습니다.”라고 말합니다. “여기에는 컴파일러 최적화, 계산 복잡성을 줄이기 위한 코드 리팩토링, 에너지 효율적으로 특별히 설계된 알고리즘이 포함됩니다. 후자는 멀티미디어 처리, 기계 학습, 센서 데이터 분석과 같이 일정 수준의 부정확성을 허용할 수 있는 애플리케이션에 대한 대략적인 컴퓨팅을 통해 달성할 수 있습니다."

Analysis
모든 것은 분석으로 시작됩니다. Ruby는 “시스템의 가상 모델을 만들 수 있습니다.”라고 말합니다. “그런 다음 우리는 사용 사례를 정의할 수 있는데, 이 맥락에서 이는 실제로 설계의 일련의 작동 모드입니다. 그것은 아직 소프트웨어가 아닙니다. 시스템은 성능 모델과 전력 모델 모두의 모델 모음으로 설명됩니다. 그리고 이러한 모델과 귀하가 정의한 사용 사례를 기반으로 전력 프로필을 제공합니다. 다음 대안은 유사한 유형의 가상 시스템 설명입니다. 이제 이에 대해 실제 소프트웨어 워크로드를 실행합니다. 더 깊이 들어가고 더 많은 가시성과 세밀한 세부 사항을 원한다면 디자인에 대한 RTL 설명을 사용할 수 있습니다. 아직 최종이 아닐 수도 있고 아직 초기일 수도 있지만 대부분 흔들리는 한 적용할 수 있습니다. 에뮬레이터를 사용하여 실제 작업을 실행합니다. 그렇게 하면 에뮬레이터가 활동 데이터베이스를 생성합니다. 대량의 데이터, 수억 개의 클록 주기 워크로드 데이터를 가져와 전력 프로필을 생성할 수 있는 에뮬레이션 중심의 전력 분석 기능이 존재합니다. 할 수 있는 일의 범위는 다양합니다.”

어떤 경우에는 그 시간이 충분히 길지 않을 수도 있습니다. Intel의 Kottapalli는 "대부분의 열 분석은 분석에 필요한 추적 길이와 시간 때문에 사전 실리콘 시뮬레이션이 아닌 실리콘 데이터를 기반으로 하는 폐쇄 루프 분석을 기반으로 합니다."라고 말합니다. “현실적인 열 프로필을 확립하기 위해 그렇게 오랫동안 시뮬레이션할 수 있는 방법은 없습니다. 우리는 다양한 종류의 워크로드와 추적을 사용하여 실리콘의 프로필 데이터를 사용한 다음 어떤 솔루션을 구축해야 하는지 분석합니다."

기간이 짧을수록 더 쉽습니다. Ruby는 “기본적인 아키텍처 결정은 일종의 전력 관점을 염두에 두고 고려해야 합니다.”라고 말합니다. “모든 처리 코어와 메모리 하위 시스템을 포함하여 시스템의 모든 부분에 대한 더 높은 수준의 더 추상적인 모델이 필요합니다. 왜냐하면 그것이 구성되는 방식이 정말 중요하기 때문입니다. 실제로 얼마나 많은 메모리가 필요합니까? 이는 기본적인 아키텍처 결정입니다. 이러한 구성 요소와 관련된 일부 전력 데이터가 필요합니다. 이 특정 작업 부하 또는 특정 작업 부하에서 CPU가 소비하는 전력은 얼마나 됩니까? DSP 코어, 하드웨어, 메모리, 칩의 네트워크는 어떻습니까? 각 작업을 수행할 때 각각 얼마나 소비됩니까? 이는 기본적인 아키텍처 결정을 내리는 데 필요합니다.”

새로운 전력 관련 도구가 많이 필요합니다. Intel의 Wilcox는 “고속, 고전력 밀도 과도 현상을 처리하기 위한 EDA 도구가 존재하지만 다른 과제도 많이 있습니다.”라고 말합니다. “다른 과제 중 일부는 더 긴 시간 상수 역학 또는 SoC 전반에 걸쳐 사물을 관리하는 방법을 살펴보는 것입니다. 나는 EDA 분야에서 이를 지원하는 것을 많이 본 적이 없습니다. 우리는 이러한 기능을 시도하고 구축하기 위해 더 많은 자체 개발 도구를 사용하고 있습니다."

이러한 아키텍처 절충을 위해 하드웨어 측면을 위한 도구가 개발되었지만 현재 소프트웨어 측면에 도움이 되는 도구는 거의 없습니다. Ruby는 “올바른 코드를 최대한 빨리 생성하려면 소프트웨어 엔지니어가 필요합니다.”라고 말합니다. “제가 정말로 필요하다고 생각하는 것은 소프트웨어 개발자를 위한 일종의 동반 기술입니다. 하드웨어용 RTL 전력 분석 도구가 있는 것처럼 소프트웨어 개발 시스템에는 이 코드가 소비하는 전력과 에너지의 양을 알려주는 일종의 전력 프로파일러가 필요합니다. 우리가 지금 AI 시대에 살고 있으니 AI 기술이 코드를 분석해준다면 멋있을 것 같아요. 전력 소비에 대한 추정치를 얻을 수 있으며 일부 AI 기술은 코드를 이런 식으로 재구성하면 많은 전력을 절약할 수 있다고 말할 수 있습니다.”

결론
하드웨어 세계는 전력 및 에너지와 관련된 벽에 부딪히고 있습니다. 해당 커뮤니티 내에서 열 제한과 우려가 커지고 있습니다. 이를 고려하지 않으면 하드웨어 기능이 성장할 수 없습니다. 그러나 이는 시스템 수준의 문제가 되는 수준에는 도달하지 못했습니다. 에너지 소비에 기여하는 모든 당사자가 같은 방에 앉아 시스템을 에너지 효율적으로 설계할 때까지는 문제에 대한 진정한 해결책을 찾을 수 없습니다.

이것에는 두 번째 측면도 있습니다. 사람들이 사용하는 도구를 생산하는 모든 사람들도 같은 공간에 들어가서 모두가 성공할 수 있도록 하는 흐름을 개발해야 합니다. 일부 열 문제를 해결하기 위해 EDA와 시스템 세계 사이에는 약간의 진전이 있었지만 아키텍처 수준에서는 진전이 덜했으며 하드웨어와 소프트웨어 세계 사이에는 거의 진전이 없었습니다. 기능에 집중하는 가상 프로토타입만으로는 충분하지 않습니다. 이를 시스템 전력 및 에너지로 확장해야 하며 컴파일러 개발자의 참여 없이는 이를 수행할 수 없습니다. 도메인 특정 컴퓨팅에는 기회가 있습니다. 왜냐하면 이러한 사람들은 이러한 문제의 결과로 하드웨어에서 새로운 방향을 취하고 있고 인접 분야에서 발전하는 것이 그들에게 충분히 중요할 수 있기 때문입니다. 하지만 그 모든 것은 앞으로도 오랫동안 남을 것 같습니다.

관련 독서
칩의 전력 가격 상승
더 많은 데이터에는 더 빠른 처리가 필요하며 이로 인해 수많은 문제가 발생합니다. 모든 문제가 명확하지도 않고 해결할 수도 없습니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://semiengineering.com/optimizing-energy-at-the-system-level/