Tài liệu này mô tả API bí danh XLA, cho phép bạn chỉ định răng cưa giữa vùng đệm đầu vào và đầu ra khi tạo chương trình XLA.
Xác định bí danh tại thời điểm biên dịch
Ví dụ: hãy xem xét một mô-đun HLO đơn giản chỉ thêm 1 vào dữ liệu đầu vào:
HloModule increment
ENTRY entry {
%p = f32[] parameter(0)
%c = f32[] constant(1)
ROOT %out = f32[] add(%p, %c)
}
Mô-đun này sẽ phân bổ hai vùng đệm 4 byte: một cho %p đầu vào và một cho %out đầu ra.
Tuy nhiên, bạn nên thực hiện cập nhật tại chỗ (ví dụ: nếu trong giao diện người dùng tạo biểu thức, biến đầu vào không còn tồn tại sau khi tính toán, như trong giá trị tăng p++).
Để thực hiện hiệu quả cập nhật như vậy, bạn có thể chỉ định bí danh đầu vào:
HloModule increment, input_output_alias={ {}: 0 }
ENTRY entry {
%p = f32[] parameter(0)
%c = f32[] constant(1)
ROOT %out = f32[] add(%p, %c)
}
Định dạng này chỉ định toàn bộ đầu ra (do {} đánh dấu) được đặt bí danh là
tham số đầu vào 0.
Để chỉ định bí danh theo phương thức lập trình, hãy xem API XlaBuilder::SetUpAlias.
Xác định bí danh trong thời gian chạy
Bí danh đã xác định ở bước trước được chỉ định trong quá trình biên dịch.
Trong quá trình thực thi, bạn có thể sử dụng API LocalClient::RunAsync để chọn xem có đóng góp vùng đệm hay không.
Các vùng đệm đầu vào của chương trình được gói trong
ExecutionInput,
chứa cây MaybeOwningDeviceMemory. Nếu bộ nhớ được chỉ định là sở hữu (quyền sở hữu vùng đệm được chuyển đến thời gian chạy XLA), thì vùng đệm đó sẽ thực sự được đóng góp và quá trình cập nhật sẽ được thực thi tại chỗ, theo yêu cầu của API đặt bí danh trong thời gian biên dịch.
Tuy nhiên, nếu vùng đệm được đặt bí danh tại thời gian biên dịch không được đóng góp trong thời gian chạy, thì tính năng copy-bảo vệ sẽ kích hoạt: một bộ đệm đầu ra bổ sung O sẽ được phân bổ, và nội dung của vùng đệm đầu vào P vốn được dùng làm bí danh sẽ được sao chép vào O (để thực thi hiệu quả chương trình như thể vùng đệm O đã được đóng góp trong thời gian chạy).