On Jul 30, 2013, at 00:41 , David Jeske <[email protected]> wrote: > On Mon, Jul 29, 2013 at 3:22 PM, Jonathan S. Shapiro <[email protected]> wrote: > I find this very interesting. The [performance] objective you are setting > makes sense, but some of the particulars strike me as challenging - notably > the vector computation goals. > I think you're taking my assertion just a bit too far. I simply mean > approaching the envelope of hardware performance should not require wholesale > jettisoning of the systems-runtime because of an achilles heel. I don't mean > that the language or runtime needs to directly support every hardware > capability itself.
While it wasn't your intention, do you think that asking for BitC/Rust-level support for something like OpenCL's or Cilk's vector datatypes is too much to expect? http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf#page=129 http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/GUID-713DA73F-69CA-447E-A3C2-043C7EBC9420.htm > AFAIK, the the stackless/first-class-continuations folks throwing stones at > the C-stack doesn't feel like an achilles heel. It hasn't been shown that > this is necessary to approach hardware performance potential. (it's more of a > code-size and clarity issue) I agree in part but you're downplaying the combination of concurrent execution with sequential syntax - it's killer. twisted's Deferred and other callback-based event models are so clunky and unfriendly to maintenance that they trip up beginners and experts alike. -ipc
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
