我不太关心垃圾收集，如果存在它应该是可选的。语言D符合要求，但我正在探索其他选择。令我感到惊讶的是，这似乎是语言中人烟稀少的地方。如果可能的话，我想要能以80％的速度运行东西的东西。
我也希望这种语言能够很好地支持多核。不一定是通过线程，而是任何不涉及大量复制的东西。例如，GNU的libstdc++并行模式对我来说是一个相当不错的抽象，但在给出预先烘焙的数组原语方面有点弱（这不是一个抱怨，给出数组原语不是它的作用）。
我怀疑我驾驶的是OCaMl类似的语言：
我不确定要使用哪些标签，欢迎提出建议。 我也希望将其设为维基，但不确定如何操作。我听说过Felix，但不知道这是否合适。
答案 0 :(得分：10)
你几乎都在描述D，特别是如果你有很长的时间，并愿意等待一些正在进行中的工作完全消失。
对多维数组的良好支持：我正在指导Google Summer of Code project focused on just that。它尚未打磨并准备好迎接黄金时段，但如果您生活在最前沿，它已经可以使用了。它还包括对BLAS和LAPACK以及表达式模板和赋值器的绑定，以便为这些库提供一个很好的包装。
D的内存管理默认方法是垃圾收集，但是存在足够的低级设施，在性能或空间效率是高优先级的情况下，您不必使用它。您可以完全访问C标准库，并可以直接使用C malloc和free。使用无类型内存块的能力还允许实现自定义分配器。我和我正在指导的GSoC学生一直在使用区域分配器，很快将对其进行审核以包含在Phobos（D标准库）中。
并行编程：请参阅标准库的std.parallelism模块。它并不专门针对阵列密集型代码，但它绝对可用于此目的。
D完全支持C ABI。您所要做的就是翻译头文件并链接到C对象文件中。甚至还有一个名为htod的工具可以自动化简单案例。
D目前比C稍慢，因为它没有多年的工作投入优化，因为重点是功能和错误修复。然而，它并不落后，几乎所有的性能差异都可以通过一个有点天真的垃圾收集器和缺乏激进的内联来解释。如果您避免在代码中性能最关键的部分使用垃圾收集器并在此处手动内联一些函数，那么它应该与C一样快。
答案 1 :(得分：3)
虽然我是OCaml和D的忠实粉丝，但就现有的图书馆而言，我发现c ++在这里是彻头彻尾的胜利者。表达式模板工作在c ++对多维数组的操作中削减了它的作用，并且已被用于创建非常高效的库，其大大优于裸c。临时数据可能会从您无法从c代码中删除的计算中删除，该代码通用性足以构成操作。在翻译期间可以自动展开循环。您可以使用开箱即用的自动并行化功能，进一步推动您对多核盒的使用达到新的高度。使用c ++ 11的类型推断功能，您可以在一个成熟的实现中获得所有请求的行为，该行为几乎可以胜过其他任何语言。
现在，我并不是说你不能在D中做同样的事情。你只是不会像uBLAS，Eigen或Blitz++那样成熟。并且您将无法使用Intel's Cilk Plus and other Parallel Building Blocks找到编译器支持。显然，在路上我毫不怀疑社区可以提供这种支持，但是c ++是我今天使用的唯一语言。
我我说你不能用OCaml，至少是标准的编译器和库，因为缺乏真正的对称多处理。像JoCaml，OC4MC等那样的东西可能提供必要的并行化，但你仍然缺乏对常用矩阵库的临时减少的深度使用。
这只是我的经历。由于缺乏对临时性的确定性破坏而使得C＃，F＃和那个家族得到这些优化变得更加困难 - 使表达模板技术变得更加笨拙。缺少模板的编译时类型推断使得许多技术无法访问。在我多年来使用的所有语言中，构建张量和旋转库，图形库，抽象代数（矩阵中表示的元素）等，c ++仍然保持对效率的最佳支持，现在在更好的类型推导环境中
答案 2 :(得分：2)
我建议F＃。
答案 3 :(得分：2)
仅供参考：Felix没有类型推断。它是合适的，并且很容易与C ++以外的任何语言的C绑定。它旨在提供低级并发（共享内存多线程）。 Felix通常可以通过使用C级编译器无法想象的高级优化来超越C。 Felix的作者将提供必要的修改，使您的代码易于阅读和编写，并且比C运行得更快（我是作者:)只是给我一些用例！