1) Very interesting blog..
I actually did some C# comercial development on Windows Mobile 2003 and it
was ok ( 32 Meg HW and using a GC!) ... also using javascript and html5 on
handhelds now , but these people are pushing frame rate graphics with
javascript ...
Also agree as we have discussed before that taking work away from the GC
heap is a good idea , this can be done via regions or like rust tasks /with
local pointers or both...
2) On mono...
Agree it will do the job , its just a shame to be of a good CIL and great
dev/deployment architecture but a poor to average implimentation of the run
time whick irks me .. note the libs are average to good. For Mono just
dont let people take benchmarks from it as reasonable.. Micro kernels got
killed because linux designed apps performed poorly on micor kernels with
some published benchmarks... And people trot out mono micro bench marks
for C# vs java or C# vs C++ all the time on linux because they cant
actually be bothered to write their test properly for windows..
re unboxed types only on the stack what you say is correct ( but can be
very usefull just on the stack ) but there are some special cases , a
string for example is actually (in Mono) an address of a char array, It
plays with the allocator and allocates the memory of the char array when it
creates the string . Hence you can not create a class as efficient as
string . The CLR does the same ..
eg
MyObject
public Valuetype val;
the value type is stored in the object , however
MyString
public char[] data;
would be created as 2 objects ..since array is a reference type.
However String is
class string
unsafe UINTPTR char; // set with unsafe &
It may be possible to apply this technique to more types in mono eg if type
is ISpecialValueType then use string type allocation however the size of
the array cannot change. I would have to trail through the bowels of mono
again to find out , as it was about a year ago that i looked at that code
for openwinrt. . That said there are special CIL codes for string eg ldstr.
Note these classes must be sealed... ( another reason why string is sealed
which people dont mention .. if it was not and you added fields it would be
a pain to create the base class data).
Too hard to think about it and boxed value types ( eg how its in the code
) as it was too long ago.
Ben
On Sun, Jul 14, 2013 at 12:56 PM, David Jeske <[email protected]> wrote:
> 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
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
