Tôi cứ nghĩ mãi về việc Dusk sử dụng các hàm máy chủ (native host functions) cho những thao tác tốn kém.
Trên giấy tờ, logic khá đơn giản. Đưa tính toán nặng ra khỏi WebAssembly, thực thi hiệu quả hơn trong môi trường máy chủ, và đồng thời giảm bớt một phần chi phí phát sinh dọc đường.
Nhưng việc làm nhanh một phần của đường thực thi không tự động khiến toàn bộ khối lượng công việc nhanh hơn theo cùng tỉ lệ. Điều này đặc biệt quan trọng khi Dusk hướng tới việc đưa thị trường tài chính lên onchain với các tổ chức được cấp phép tại EU—nơi kiến trúc cuối cùng phải hoạt động tốt dưới tải thực tế, chứ không chỉ trông có vẻ hiệu quả trên giấy.
Điều tôi chưa biết là liệu thiết kế hàm máy chủ của Dusk có thực sự loại bỏ một điểm nghẽn (bottleneck) chi phối các khối lượng công việc thực tế hay không, hay chủ yếu chỉ tăng tốc cho phần công việc hóa ra lại chiếm tỷ trọng nhỏ trong tổng thời gian thực thi.
Những chi tiết đáng theo dõi gồm: các thao tác nào được chuyển ra khỏi WASM, chúng nhanh hơn đến mức nào, và các thao tác đó chiếm bao nhiêu trong một khối lượng công việc Dusk mang tính đại diện.
Kiến trúc đưa ra một lý do tốt để kỳ vọng có cải thiện. Nhưng đó là bằng chứng yếu hơn so với việc quan sát cùng một loại khối lượng công việc tạo ra một mức tăng có thể đo được, lặp lại được trong thực tế.
Tôi ít quan tâm đến mức tăng tốc mang tính lý thuyết của một nguyên thủy cụ thể hơn là mức nó thay đổi hiệu năng của chính khối lượng công việc mà Dusk thực sự chạy.
Câu hỏi là liệu Dusk đã loại bỏ một điểm nghẽn hệ thống thực sự, hay chỉ đơn giản là tăng tốc một phần của luồng xử lý mà không kéo hiệu năng tổng thể đi xa.
Tôi đang theo dõi các benchmark riêng của Dusk nhằm cô lập phần lợi ích từ hàm máy chủ và chỉ ra điều đó quan trọng đến mức nào ở cấp độ khối lượng công việc.
#dusk $DUSK @Dusk
Trên giấy tờ, logic khá đơn giản. Đưa tính toán nặng ra khỏi WebAssembly, thực thi hiệu quả hơn trong môi trường máy chủ, và đồng thời giảm bớt một phần chi phí phát sinh dọc đường.
Nhưng việc làm nhanh một phần của đường thực thi không tự động khiến toàn bộ khối lượng công việc nhanh hơn theo cùng tỉ lệ. Điều này đặc biệt quan trọng khi Dusk hướng tới việc đưa thị trường tài chính lên onchain với các tổ chức được cấp phép tại EU—nơi kiến trúc cuối cùng phải hoạt động tốt dưới tải thực tế, chứ không chỉ trông có vẻ hiệu quả trên giấy.
Điều tôi chưa biết là liệu thiết kế hàm máy chủ của Dusk có thực sự loại bỏ một điểm nghẽn (bottleneck) chi phối các khối lượng công việc thực tế hay không, hay chủ yếu chỉ tăng tốc cho phần công việc hóa ra lại chiếm tỷ trọng nhỏ trong tổng thời gian thực thi.
Những chi tiết đáng theo dõi gồm: các thao tác nào được chuyển ra khỏi WASM, chúng nhanh hơn đến mức nào, và các thao tác đó chiếm bao nhiêu trong một khối lượng công việc Dusk mang tính đại diện.
Kiến trúc đưa ra một lý do tốt để kỳ vọng có cải thiện. Nhưng đó là bằng chứng yếu hơn so với việc quan sát cùng một loại khối lượng công việc tạo ra một mức tăng có thể đo được, lặp lại được trong thực tế.
Tôi ít quan tâm đến mức tăng tốc mang tính lý thuyết của một nguyên thủy cụ thể hơn là mức nó thay đổi hiệu năng của chính khối lượng công việc mà Dusk thực sự chạy.
Câu hỏi là liệu Dusk đã loại bỏ một điểm nghẽn hệ thống thực sự, hay chỉ đơn giản là tăng tốc một phần của luồng xử lý mà không kéo hiệu năng tổng thể đi xa.
Tôi đang theo dõi các benchmark riêng của Dusk nhằm cô lập phần lợi ích từ hàm máy chủ và chỉ ra điều đó quan trọng đến mức nào ở cấp độ khối lượng công việc.
#dusk $DUSK @Dusk