关键在于float的组织与调度方式：cpu端用floatvector按硬件向量长度批量处理对齐数据，gpu端需组合为float3/float4x4等类型配合着色器并行运算，二者均依赖结构化设计而非float本身。
关键不在 float 类型本身，而在它如何被组织、调度和嵌入计算流程中。float 只是 32 位浮点存储单元，无法“动态接收矩阵”——真正起效的是：用 float 构建向量/矩阵结构，并在 CPU 或 GPU 合适层级上驱动批量、对齐、低开销的运算。
CPU 端：用 FloatVector 批量处理图像数据
Java 中的 FloatVector 不是容器，而是硬件向量指令的抽象。它按 CPU 当前最优向量长度（如 AVX-512 下 16 个 float）自动分块加载、计算、写回，适合规则访存场景，比如 YUV 转 RGB、卷积滤波等。
- 输入数组必须内存连续且按向量长度对齐（如 64 字节），否则跨步访问会严重降速
- 用 SPECIES_PREFERRED 让 JVM 自动匹配当前 CPU 指令集，无需手动判断 SSE/AVX
- 循环边界需按 SPECIES.length() 对齐；剩余元素用标量补足，避免越界或填充浪费
- 示例：对 1920×1080 灰度图做线性拉伸，FloatVector 实现比传统 for 循环快 2–3 倍
GPU 端：用 float3/float4x4 驱动并行着色器运算
GPU 上的 float 是向量计算基本粒度。单靠 float 无意义，必须组合为 float3（颜色）、float4x4（变换）等类型，配合纹理采样和内置函数，才能释放并行吞吐能力。
- 在片段着色器中，用 tex2D(y_tex, uv).rgb 一次读取三通道，而非三次单通道采样
- YUV→RGB 转换应调用 mul(yuv_matrix, yuv)，编译器可将其优化为单条 SIMD 指令
- 所有运行时矩阵（如 MVP、光照矩阵）必须由 CPU 预计算好，通过 uniform 传入；避免在着色器里 if/else 动态构造
- Unity Shader Graph 中控制曝光、对比度的 Float 节点，建议设为 [0, 1] 范围并启用 Half 精度，降低寄存器压力
规避常见效能陷阱
高频图形渲染对数值稳定性与访存效率极其敏感，几个易忽略但影响大的点：
- 不要在 CPU 端用 float 数组手写 4×4 矩阵乘法（如顶点变换），改用 Eigen/GLM 等专用库，或直接交由 GPU 处理
- 避免在循环内反复执行 (float)i / width 这类归一化操作；提前算好步长常量（如 inv_width = 1.0f / width）
- 不把 float 当“万能矩阵载体”——图像像素矩阵本质是多维数组，需结合内存布局（如转置重排）、通道顺序（RGB/BGR）、精度范围（0–255 或 0–1）统一设计
不复杂但容易忽略：float 是工具，不是方案。决定吞吐上限的，是它所处的结构、路径与约束条件。
