1. .. im sure bounds checking is very tricky but Mono doesnt really try . Java does it well via hotpot type compilations which the CLR is behind in. However if you have natural numbers then you can cast the type to say a nat 1...N and hence the compiler can go it is over the enitre range and omit the bounds check.
2.. I know they are going the llvm way but if your using this why not use llvm direct... the only value mono gives then is the .NET libs ... I havent checked it much because - LLVM everyone says is too slow for a jit so then you may as well statically compile. - Its not default so only a small sub set of a small number of users - THe clinch is " LLVM is not able to support some of the features that Mono needs, so in those cases the JIT compiler will still fall back to Mono's JIT engine (methods that contain try/catch clauses or methods that do interface calls)." try catch , generics and inteface calls is a lot of my code .... so your really using monos poor jit with LLVM just for a c like method... it seams a "dodgy" hybrid ... and raises in my questions about where the team think or want to go.. I do know they use a slighttly modified older LLVM set not the current one. This may have changed with Xamarin ( since they want betetr multi platform support) 3. Yes debugging and working in VS is very nice .. that said im sure you can write a debugger extention for VS. The C++ has one . There is an LLVM CIL output which could be used for debugging , testing and then you have static compilation as well. 4. Why rust ? Rust is language similar to bitC ... that generates LLVM and is self hosting. They took lessons from the bitc project and added traits use regions are working on a gc etc .. To me to get Bitc working just use rust and change a few language things.. Get the LLVM to CIL output working ( a summer student at MS wrote one as IR to IR is not that hard ) and rust could also generate CIL , and have the option of static compilation with the main point being your miles ahead on the maturity scale . Rust is getting close to v1 eg something you would use in a real project and has an active team. I think its well worth watching Rust to see if Traits and modern cocepts can get within 10% of c in terms fo performance , they are a fair way of at the moment . "Fair enough, and point well taken. The question for now is: what's the best place to do language bring-up rather than a high-performance implementation. Given that statement of the problem, does your assessment change?" Isnt the purpose of these pointer array value types is performance .. As a protype / demonstrator why not just use Windows / CIL which has better CIL tooling and forget mono ( it will probably run on mono but few will use it like that , and the benchmark comparisons are dangerous so i wouldnt waste much time) .. If your after something more long term , then the LLVM ( or Rust ->LLVM for a lot of language stuff includes ) seems better as you can convert IR to CIL relatively easy as well as offering static compilation and improving GC/JIT support. This may help Iron python is open source python running on CLR ( and mono) . http://ironpython.codeplex.com/ Sorry to harp on about rust ( just want to see some of the nice stuff bitC had especially constraints , Natural numbers and the lib what little there was was very powerful for the amount of code) , just dont understand what do you offer in the CLR space that F# and C# unsafe does not ? Ben On Sun, Jul 14, 2013 at 10:23 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Sat, Jul 13, 2013 at 6:28 PM, Bennie Kloosteman <[email protected]>wrote: > >> I had a very close look at mono last year and was very disapointed... >> > > Bennie: > > First, I want to say thanks for this feedback. It's very useful. A couple > of quick reactions and questions. > > 1. Bounds check elimination in CLR is a *lot* harder than it should be. > The definition of CLR leads to some aliasing problems for bounds checks in > the presence of multiple threads that are *very* hard to eliminate. Not > claiming that mono does this well - in fact, I don't have any idea how well > or badly mono does. What I *can* say is that I had an extended discussion > about this with some people very knowledgeable about CLR, and it's very > hard to get this right. > > 2. How much of what you say is true in the mono-llvm path? There has been > a lot of work in that direction, and I'm not clear what the yield has been. > Do you know? If you are able to expand on the issues in the mono-llvm path, > that would be very helpful to me. > > 3. One of my concerns is debugging. Whatever mono's flaws may be, the > debugging and introspection support in CLR (therefore in mono) is pretty > rich. My intuition is that this will be valuable in debugging my compiler, > even if CLR is not the ultimate target. I have no intuitions at all about > how much this is true in LLVM. > > 4. Why a direct fork of Rust? I'm completely in the dark about how Rust is > relevant here. Can you suggest things I should go read up on to get my head > around it? > > >> If you just want to get something out there mono will do the job and >> fairly quick ( as the run time is reasonably easy to targtet ) but it wont >> go anywhere.. >> > > Fair enough, and point well taken. The question for now is: what's the > best place to do language bring-up rather than a high-performance > implementation. Given that statement of the problem, does your assessment > change? > > > Jonathan > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
