Couple thoughts.. 1) btw, if you have not seen it, this recent tome of a blog post has an interesting view of the performance-vs-gc fight..
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ 2) On mono... Bennie's detailed info is pretty fantastic. At the same time, it's not like those details change the fact that IMO CLR it's one of the most attractive currently available runtimes for what you want to do. Hardcore tests can be run on Windows, and if using CLR leads to some effort going into improving Mono, that effort can have benefits regardless of the outcome of the experimental language project. 3) Regarding V8/JS... What I'm going to write here is *not* to be taken as advocacy for V8. If I understand your goals at all, the CLR is a better fit. I'm simply going to share some more thoughts, because I don't think it's a *crazy* option to consider. I'm also trying to stretch to give you at least some other option, because there are few. > [V8] runs on a bytecode engine designed for a dynamically typed language (i.e. > javascript) that has no support for unboxed types To me, you have described both the JVM and V8 here, as their handling of dynamism at the object level is very similar. Both of them do entirely dynamic method dispatch, optimized through JIT/PIC. Both of them have no ahead-of-time compilation, partially because there is no larger code loading unit (like CLR assemblies). Both of them treat primitive value types differently than real objects. In many, many ways they are the same design. The fact that JVM supports type-overloaded methods can be thought of as simply a name-mangling trick, and you can do the same thing with your own language on V8. The main difference I see is that JVM bytecodes are arguably faster to parse than Javascript code -- hardly a show-stopper. My point? --> If JVM+value-types is an option, then V8+TypedArrays should be an option -- and arguably a better option, since V8+TypedArrays is in use today and likely to be well supported going forward. > 1. Must support unboxed types to *at least* the extent they are supported in CLR Typesafe Arrays-of-aggregate-value-types is a compromise laiden path. Because of this, I fear choices like "at least the unboxed type support in the CLR" will mean only the CLR qualifies, since everyone fights with these tradeoffs and those fights result in different outcomes. (look at bitc!) I look at unboxed types as attractive for reducing the amount of memory touched *at-all* by the GC tracing. To that end, putting GC pointers in there is fighting against the goal, since it means they must be traced. Further, even in CLR, one can't hold long-lived pointers to structs (only ref-pointers descending on the real stack, where liveliness is assured because the stack holds a pointer to the container). Therefore, if arrays-of-valuetypes are a useful solution to a bunch of problems (like arrays of structs are in C) there will need to be a typesafe solution to reference them which does not rely on GCed pointers (to mirror C struct pointers).. Perhaps some form of array-index-handle. ...So maybe it's not totally *crazy* to consider TypedArrays as a solution framework. > I can see that if you are willing to completely abandon debugging, you can make > [TypedArrays] work for unboxed objects containing no object references . That is: for > over-glorified byte arrays, which is exactly what these extensions were meant for. I don't understand what debugging challenges you perceive to be specifically about typed-arrays. If you define your own language, your debugger can access and trust a struct definition to introspect typed-array contents, can it not? I think the primary debugging challenge with V8, is that V8 itself doesn't come wrapped up in a tidy-IDE with foreign-language-source-debugging. However, webstorm does it, so it's not out of the question... http://www.industrieit.com/blog/2013/04/webstorm-6-ide-a-winner-for-client-side-development/
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
