From 20b736b305d6888afd7095c8f059f1c6a608c1e1 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 2 Oct 2021 20:26:02 +0100 Subject: [PATCH] --- 3d_gpu/architecture/dynamic_simd.mdwn | 34 ++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/3d_gpu/architecture/dynamic_simd.mdwn b/3d_gpu/architecture/dynamic_simd.mdwn index 0d1e9d805..e5eacd72c 100644 --- a/3d_gpu/architecture/dynamic_simd.mdwn +++ b/3d_gpu/architecture/dynamic_simd.mdwn @@ -123,9 +123,41 @@ basic HDL is literally an order of magnitude larger: with m.ElIf(....) .... - # Alternative implementation concepts +Several alternative ideas have been proposed. They are listed here for +completeness. + +* **Wrapper classes**. A dsl.Module wrapper class which duplicates the + entirety of the dsl.Module functionality with "redirection" functions + and a dsl.Module instance as a member variable. In the rare instances + where the function is different it is expected to provide a replacement + rather than call the dsl.Module variant. +* **Replacement for dsl.Module**. This idea is to implement a full total + replacement for dsl.Module, called dsl.SIMDModule (or other). +* **Monkey-patching dsl.Module**. This idea intrusively modifies dsl.Module + with external functions. + +All of these ideas, unfortunately, are extremely costly in many different ways: + +1. Any overrides of any kind give a catastrophically fatal impression + that the high-level language behaviour might in some tiny way be different, + purely because of the very *existence* of an override class. +2. Proponents of such override mechanisms (and there have been many) + fundemntally misunderstand the distinction between Type 1 (AST) low-level + and Type 2 (dsl.Module) high-level nmigen language constructs, and + miss the fact that dsl.Module (Type 2) is 100% implemented *in* AST + (Type 2) constructs. +3. Wrapper classes are a maintenance nightmare. Unless included in the + library itself, any update to the library being wrapped is a huge risk + of breaking the wrapper. Long-term this is completely unsustainable. + Likewise monkey-patching. +4. Wrapper classes introduce a huge performance degradation. Every function + requires one additional function call. Every object instantiated requires + both the wrapper class to be instantiated and the object being wrapped, + every single time. Memory requirements double; performance degrades. + Both are unacceptable. + # Rationale / Introduction To save hugely on gate count the normal practice of having separate scalar ALUs and separate SIMD ALUs is not followed. -- 2.30.2