@@ -93,8 +93,28 @@ This is covered in the [tooling](Tooling.md) section.
93
93
## Asynchronous Signals
94
94
* TODO
95
95
96
- ## Non-fixed-width SIMD
97
- * TODO
96
+ ## "Long SIMD"
97
+ * The initial SIMD API will be a "short SIMD" API, centered around fixed-width
98
+ 128-bit types and explicit SIMD operations. This is quite portable and useful,
99
+ but it won't be able to deliver the full performance capabilities of some of
100
+ today's popular hardware. There is an opportunity for someone to propose a
101
+ "long SIMD" model which will generalize to wider hardware vector lengths make
102
+ more natural use of advanced features like vector lane predication,
103
+ gather/scatter, and so on. Interesting questions to ask of such an model will
104
+ include:
105
+ * How will this model map onto popular modern SIMD hardware architectures?
106
+ * What is this model's relationship to other hardware parallelism features,
107
+ such as GPUs and threads with shared memory?
108
+ * How will this model be used from higher-level programming languages?
109
+ For example, the C++ committee is considering a wide variety of possible
110
+ approaches; which of them might be supported by the model?
111
+ * What is the relationship to the "short SIMD" API? "None" may be an
112
+ acceptable answer, but it's something to think about.
113
+ * What non-determinism does this model introduce into the overall platform?
114
+ * What happens when code uses long SIMD on a hardware platform which doesn't
115
+ support it? Reasonable options may include emulating it without the
116
+ benefit of hardware acceleration, or indicating a lack of support through
117
+ feature tests.
98
118
99
119
## Operations which may not be available or may not perform well on all platforms
100
120
* Fused multiply-add.
0 commit comments