On Jul 30, 2013, at 06:58 , David Jeske <[email protected]> wrote:
> On Tue, Jul 30, 2013 at 2:31 AM, Ian P. Cooke <[email protected]> wrote:
> 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?
>
> I think if a language system can't support OpenCL (with competitive
> performance), it doesn't deserve to be called a systems programming language.
> The abstraction level at which it injects this kind of functionality is a bit
> irrelevant to me (intern vs library, etc. etc)
>
> The net result of this is that it's necessary to *either* provide run-time
> code generation in the language, or support run-time code generators in the
> language. If neither of these is allowed then it's not possible to do many
> many optimizations.
>
That's a good point.
>> 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.
>
> I'm really not. I'm making a set of brutal and hopefully mostly-objective
> culling rules for the minimum viable systems programming language must
> include. In C we can author Python, and twisted, and stackless without
> stop-the-world so C seems like it does not have any achilles heel WRT this
> issue. We can't say the same about JVM.
>
I think we could with a HotSpot patch:
http://classparser.blogspot.com/
I was watching that development for a while and it looked good to me. I never
saw any indication as to why they didn't include the work since it was finished.
I agree continuations are not a required language feature for a minimal
language although I believe the ability to implement them in a library without
runtime modification should be a requirement. If tasks are part of the
language/runtime (e.g. Rust, Go) and allow as much control then I think I would
not be reaching for continuations.
-ipc
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
