나는 GPU 프로그래머는 아니지만, 나 같은 사람도 쉽게 사용할 수 있을 것 같음. GPU와 CPU를 사용하는 간단한 데모를 만들어 보았음. 결과는 다음과 같음
CPU에서 5000x5000 크기의 무작위 행렬 100개 생성
CPU로 행렬 더하기
CPU 행렬 덧셈 완료 시간: 0.6541초
CPU 결과 행렬 크기: (5000, 5000)
GPU에서 5000x5000 크기의 무작위 행렬 100개 생성
GPU로 행렬 더하기
GPU 행렬 덧셈 완료 시간: 0.1480초
GPU 결과 행렬 크기: (5000, 5000)
API가 정말 간단해서 더 깊이 파볼 가치가 있음. CUDA 프로그래밍은 이런 고수준의 것이 없으면 큰 작업처럼 보임
Python이 이런 것들의 대상이 되는 이유가 무엇인지 궁금함. 많은 프로젝트가 Python 지원을 추가하는 것을 보았음. Python 코드베이스가 다른 것들보다 쉽게 다양한 타겟으로 컴파일될 수 있는지 궁금함
Pytorch가 이 나오기 전에 큰 모멘텀을 얻어서 다행임. 이제 우리는 병렬 계산을 위한 진정한 플랫폼 독립적인 반표준을 가짐. NVIDIA에 국한되지 않음
NVIDIA 백엔드와 관련된 Pytorch의 부분이 이제 Python에서 직접 구현될 수 있음
중요한 점은 최종 사용자/개발자에게는 중요하지 않거나 중요하지 않아야 한다는 것임
이 새로운 플랫폼이 Python을 통해 GPU 계산의 전체 개념을 게임 같은 더 많은 도메인으로 확장할 수 있을지도 모름
Python을 통해 주로 GPU에서 Rust 게임을 실행하는 것을 상상해보라
CuTile은 여러 면에서 OpenAI의 Triton의 후속작처럼 느껴짐. 타일/블록 수준의 원시 기능과 TileIR뿐만 아니라 CuPy에서 적절한 SIMT 프로그래밍 모델도 얻고 있음. 올해 GTC에서도 많은 사람들이 주목하지 않은 것 같음. 매우 멋진 것임
그럼에도 불구하고 CPU와 관련된 발표나 토크는 거의 없었음. Grace CPU가 발표된 지 꽤 되었지만, Nvidia CPU와 GPU에서 원활하게 작동하는 일반화된 추상화를 곧 볼 것 같지 않음
병렬 알고리즘을 매일 작업하는 사람에게는 이것이 문제임. NSight와 CUDA-GDB로 디버깅하는 것은 여전히 원시 GDB와 같지 않으며, 먼저 CPU에서 알고리즘을 설계한 다음 GPU로 포팅하는 것이 훨씬 쉬움
컴파일러 분야의 모든 팀 중에서 Modular는 LLM 열풍에 완전히 휩싸이지 않고 여러 플랫폼을 아우르는 추상화와 언어를 적극적으로 구축하는 몇 안 되는 팀 중 하나임. 이 환경에서 점점 더 가치가 있음. 더 많은 사람들이 Mojo를 실험해 보기를 바람. 아마도 그것이 우리가 매일 직면하는 CPU-GPU 간의 격차를 마침내 메울 수 있을지도 모름
JAX와 어떻게 비교되는지 매우 궁금함
JAX는 Nvidia뿐만 아니라 다른 브랜드의 GPU에서도 실행되는 Python 코드를 작성할 수 있게 해줌 (지원은 다양함). 유사하게 NumPy 함수의 드롭인 대체품을 가지고 있음
이것은 Nvidia만 지원함. 하지만 JAX가 할 수 없는 일을 할 수 있는지? 사용하기 더 쉬운지? 고정 크기 배열 지향성이 덜한지? 한 브랜드의 GPU에 자신을 고정시키는 것이 가치가 있는지?
이것은 대단함. AI 분야에서 NVIDIA의 대안으로 AMD + ROCm을 고려하던 사람은 더 이상 없을 것임
나는 GPU 실행을 위해 효과적으로 코드를 작성할 정도로 C++을 배우지 못하는 (배우지 않을) 사람 중 하나임. 하지만 Python을 통해 GPU로 직접 파이프라인을 가질 수 있음. 놀라움
효율성의 의미는 엄청남. PyTorch와 같은 Python 라이브러리뿐만 아니라 NVIDIA GPU에서 실행되는 모든 것에 대해
효율성을 개선하는 것을 보는 것을 좋아함. 우리는 OpenAI와 Google이 모든 GPU를 구동하기 위해 얼마나 많은 원자력 발전소가 필요할지에 대해 끊임없이 듣고 있음
Rust 지원은 다음인가? 현재 나는 내 데이터 구조를 커널로/커널에서 바이트 배열로 수동으로 [디]직렬화하고 있음. CUDA가 C++에서 제공하는 것처럼 진정으로 공유되는 데이터 구조를 갖는 것이 좋을 것임
Python은 정말로 프로그래밍 언어의 링구아 프랑카로 자리 잡고 있음. FOSS 르네상스에서 채택이 급증하고 있으며, 우리가 가진 것 중 가장 가까운 만능 도구라고 생각함
PEP 모델은 자기 개선과 표준화를 위한 좋은 수단임. uv와 BeeWare와 같은 프로젝트 덕분에 패키징과 배포는 곧 해결될 문제임. 매년 성능 개선이 계속될 것이라고 확신함
이것은 아마도 Python이 일반적으로 이끌어온 것, 즉 더 많은 것들이 더 빨리 시도되고 더 빠른 언어에 남아 있는 것을 이끌 것임. 전반적으로 이것은 훌륭한 움직임임. 확실히 이것을 가지고 놀기를 기대하고 있음
CUDA는 C와 C++에서 태어났음. C++을 확장하고 CUDA C라고 부르는 대신 실제로 CUDA의 C 변형을 구현했으면 좋겠음
Hacker News 의견
나는 GPU 프로그래머는 아니지만, 나 같은 사람도 쉽게 사용할 수 있을 것 같음. GPU와 CPU를 사용하는 간단한 데모를 만들어 보았음. 결과는 다음과 같음
Python이 이런 것들의 대상이 되는 이유가 무엇인지 궁금함. 많은 프로젝트가 Python 지원을 추가하는 것을 보았음. Python 코드베이스가 다른 것들보다 쉽게 다양한 타겟으로 컴파일될 수 있는지 궁금함
Pytorch가 이 나오기 전에 큰 모멘텀을 얻어서 다행임. 이제 우리는 병렬 계산을 위한 진정한 플랫폼 독립적인 반표준을 가짐. NVIDIA에 국한되지 않음
CuTile은 여러 면에서 OpenAI의 Triton의 후속작처럼 느껴짐. 타일/블록 수준의 원시 기능과 TileIR뿐만 아니라 CuPy에서 적절한 SIMT 프로그래밍 모델도 얻고 있음. 올해 GTC에서도 많은 사람들이 주목하지 않은 것 같음. 매우 멋진 것임
JAX와 어떻게 비교되는지 매우 궁금함
이것은 대단함. AI 분야에서 NVIDIA의 대안으로 AMD + ROCm을 고려하던 사람은 더 이상 없을 것임
Rust 지원은 다음인가? 현재 나는 내 데이터 구조를 커널로/커널에서 바이트 배열로 수동으로 [디]직렬화하고 있음. CUDA가 C++에서 제공하는 것처럼 진정으로 공유되는 데이터 구조를 갖는 것이 좋을 것임
Python은 정말로 프로그래밍 언어의 링구아 프랑카로 자리 잡고 있음. FOSS 르네상스에서 채택이 급증하고 있으며, 우리가 가진 것 중 가장 가까운 만능 도구라고 생각함
이것은 아마도 Python이 일반적으로 이끌어온 것, 즉 더 많은 것들이 더 빨리 시도되고 더 빠른 언어에 남아 있는 것을 이끌 것임. 전반적으로 이것은 훌륭한 움직임임. 확실히 이것을 가지고 놀기를 기대하고 있음
CUDA는 C와 C++에서 태어났음. C++을 확장하고 CUDA C라고 부르는 대신 실제로 CUDA의 C 변형을 구현했으면 좋겠음