[Mono-dev] Cilk for Mono
stifu at free.fr
Fri Nov 5 06:38:15 EDT 2010
What I meant by "runtime", is what you called "virtual machine".
If it doesn't need to be changed, then yeah, .NET compatibility should not
be an issue.
I can't help further, gotta see if the Mono team thinks this is both
desirable and doable. And whether they'd consider doing it themselves, or if
they will only include it if community members do it...
IMHO, though, implementing missing stuff (+ fixing, optimizing stuff) that
.NET supports is more of a priority. I value stability and interoperability
more than extras.
> What do you mean for the "runtime"?
> In the cilk-5.4.6 for C
> .cilk and .cilkh files is first compiled to vanilla .c and .h files by
> the cilk2c compiler. The generated .c and .h files includes headers
> of the runtime library (in C). These generated .c and .h files are in
> turn compiled by an ordinary C compiler such as gcc and linked to the
> runtime library.
> As discussed in my previous posts, Cilk can have similar arrangement in
> The extended language (C# plus spawn and sync) is parsed by dmcs, then
> the AST is expanded in-place within dmcs to conform to vanilla C#, and
> finally dmcs emits CIL that calls the runtime library that is written
> in vanilla C# and compiled into CIL.
> Therefore compatibility with .NET should not be affected, because:
> - the virtual machine and the CIL language is not changed.
> - any valid C# programs are also valid in the extended language
> So any program that can run on vanilla .NET should be run on mono.
> Finally, we can make the Cilk support to be off by default, and can be
> turned on by supplying a flag to dmcs, such as "-fcilk".
> In the default mode, cilk keywords are not allowed and code generated
> will *not* link to cilk runtime library
> if "-fcilk" is addedm then dmcs will enter the cilk mode and produce
> CIL that may call the cilk runtime library, and the resultant code
> would run natively in mono, or if run on native .NET, the cilk runtime
> library path must be made available to .NET
> Would this work?
> On Fri, Nov 5, 2010 at 9:56 PM, Stifu <stifu at free.fr> wrote:
>> Would this require a change in the runtime, or only in the compiler?
>> If the runtime needs to be updated, that would break compatibility with
>> I doubt this could work as an external library, right?
>> kcleung wrote:
>>> I am surprised that the Cilk task-stealing mechanism, which is
>>> algorithmically proven to be the most efficient, is not included in C#
>>> 5.0 specification.
>>> However would it be feasible for us to implement Cilk in dmcs for Mono
>>> The resultant language will have the new keywords "spawn" and "sync"
>>> (with support for atomic "+=", "-=" operators on spawn results) and
>>> inlets. The compiler should also forbid using results from spawn
>>> before calling "sync"
>>> Beside performance advantages, the cilk model is really much simpler
>>> than the async interface in C# 5.0
>>> Since Cilk (developed by MIT) is *not* patented, there should be no
>>> legal obstacles preventing us from implementing the Cilk flow model
>>> onto C#, or other mono / .NET languages.
>>> What do you think?
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>> View this message in context:
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
View this message in context: http://mono.1490590.n4.nabble.com/Cilk-for-Mono-tp3028260p3028453.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
More information about the Mono-devel-list