[OV] Compare OV vs GC compilation time
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 15/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp
- Lĩnh vực
- compilers, performance
Hướng nghiên cứu
Start where a finalized cldnn::primitive is handed off to compilation in the GPU plugin, and put timing around the linalg -> binary stage including the IGC invocation; on the GPU-native side measure the same point while skipping the transformation_pipeline and cldnn::graph passes. Begin with a single-operation graph (matmul or SDPA) to check the ~600ms vs ~1ms estimate, then repeat per kernel type (oneDNN pre-compiled binaries vs pure CL kernels). Done means per-stage numbers that show where IGC time goes and why it differs from OV-GPU.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
We have to formally compare model's compilation time in OV via MLIR and GPU-Native path. We agreed to exclude ov -> mlir conversion time out of the scope, what we're interested in is the time we spend in GC during linalg -> binary compilation (including IGC time). We have to compare against GPU-plugin-native's path and understand what causes the difference. When measuring GPU-plugin-native's path we have to exclude transformation_pipeline and cldnn::graph passes (as MLIR goes through the same path). We have to identify where a finalized cldnn::primitive starts compiling and measure its time.
It's suggested to first compare compilation on a graph of a single operation (matmul/sdpa?). We have an estimate of ~600ms for MLIR pipeline(with IGC taking ~50% of the time) and ~1ms for GPU-native pipeline(which also somehow includes IGC compilation). We have to verify if this is a true estimate and find out why IGC takes so much time in our case (compared with OV-GPU). My assumptions is that it's because oneDNN uses templates of pre-compiled binaries.
There are several "types" of kernels that are used inside of GPU plugin. We have to measure and understand the compilation flow for all of them. I know about two types:
- oneDNN kernels(pre-compiled-binaries?) - are written on oneDNN side, OV simply invokes these.
- Pure cl-kernels - are written&compiled on OV's side
- ??? something else
- Ngôn ngữ chính
- C++
- Star
- 64
- Fork
- 20
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 16
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của intel/graph-compiler
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 50/100
intel/graph-compiler#459 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của intel/graph-compiler
Issue tương tự
-
runtime: lf_f128_mod is documented as fmodq (truncating) but implements floor-based modulo; unusedĐang mởinternal correctness low priority rt_lib
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 87/100
-
PriorityNotificationQueue::wakeUpAll() loses the wake-up for a thread that is not waiting yetCó thể đã có người làm @matejk đã nhận hôm nay. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
pocoproject/poco#5674 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug docs GUI
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
sonic-pi-net/sonic-pi#3609 ·
-
Unreachable code warningĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
SanderMertens/flecs#2395 ·
Maintainer thường phản hồi trong vòng 1 ngày