Skip to content

分发与内核

BitCal 记录 dispatch,是为了定义支持边界,而不是为了给项目增加“很底层”的人格设定。读者需要知道实现自由从哪里开始,因为这条线决定了哪些变化属于架构,哪些只是 backend 工程。

分发边界

公开契约与实现自由
公开契约稳定入口头文件 · 所有权/借用角色 · 算法语义分发边界分发策略特征检测、路由、回退选择内核族AVX2 主路径,标量可移植底线微调层指令选择、展开、对齐策略
契约线把用户可见角色与语义留在上层,把 dispatch policy 与 kernel 替换留在下层。

内核族

内核族当前文档姿态为什么要单独分层
Scalar floor保留的可移植基线即使没有宽向量路径,也要有 correctness floor。
AVX2 path当前主优化与主证据目标现阶段 benchmark 叙事主要集中在这里。
Future x86 variants只能作为设计方向提及在没有保留证据前,不应把它们写成现时主张。

支持边界

dispatch 与 kernel 必须服从当前公开支持姿态:

  • Linux / Windows x86-64 是主要优化与验证目标;
  • 次级目标 可以继续保持可构建,但不能自动继承更强性能或成熟度承诺;
  • 公开文档 只有在 backend 细节会改变可见语义、benchmark 语境或支持边界时,才应主动讨论它。

读者应带走什么结论

只要公开角色模型、算法语义和 include seam 仍然一致,dispatch 层就可以被积极重写。这也是为什么下一站应该是 Performance:benchmark claim 属于这条边界线以下,而不是属于它以上。

Whitepaper-first technical documentation for BitCal vNext.