> On Mar 14, 2016, at 12:52 PM, Steve Fink <[email protected]> wrote:
>
> On 03/14/2016 06:35 AM, Brian Barnes wrote:
>> The more we discuss this, the more I think this problem isn't solvable
>> without something radical that makes Javascript more C like. Which, I think,
>> is probably some of the reason for asm.js.
>>
>> The problem: People want to create realtime games, VR, animations, without
>> stutter. You can get away with this by pre-allocating everything into
>> global (I do a lot of that and get solid, predictable frame rates:
>> www.klinksoftware.com/ws) GC engines just aren't the place for that.
>>
>> A real multi-part solution would be:
>>
>> 1. Introduce types. Make them pass by value, and "set by value". This
>> allows local variables to be on the stack, and allows for faster to
>> compilation steps as you don't have to run functions to analyze the types.
>>
>> foo(x)
>> {
>> int y; // local, on stack
>>
>> foo2(y); // the y inside of foo2 is a local in foo2, passed by value
>> globalY=y; // this is also copying the value, y is still local
>>
>> y=0.0; // probably an error, should be forced to convert
>> y=Math.trunc(0.0); // not an error
>>
>> return(y); // also a copying of the value
>> // y is popped from the stack
>> }
>>
>> This isn't new, it's how C obviously does it.
>
> Your example is of primitive types, so I will only address that. You are
> asserting that this would help performance. I assert that the existing
> dynamic type-discovery mechanisms get you almost all of the performance
> benefit already (and note that I'm talking about overall performance -- code
> that runs 1 million times matters far, far more than code that runs a handful
> of times during startup.) And they work for more situations, since they
> capture types of unnamed temporaries and cases where the type is not
> statically fixed but during actual execution either never changes or stops
> changing after a startup period. And they do not require the programmer to
> get things right.
>
> Do you have evidence for your assertion? (I haven't provided evidence for
> mine, but you're the one proposing a change.)
I didn’t assert that it would help performance, I said it would reduce GC load,
because primitives could be put on the stack, and popped off, and never hit the
heap, and are never considered in the GC. Less objects in the GC could even
eliminate GC if you pre-allocate and just have local primitives, because you
never create an object yourself.
If there is no GC, performance will improve, that’s just logical. Performance
was never the concern, pauses due to GC were.
>
>> 2. Introduce a new mode that changes the behavior of new in scripts to
>> require a free, say "use free"; . Heaps are compacted (if required) on new,
>> so realtime can avoid that by pre-allocating.
>>
>> {
>> let x=new myClass(y);
>> free(x);
>> }
>>
>> This would probably require a separate heap, away from the GC heap.
>>
>> I'm just thinking that anytime spent on a solution that tries to put some
>> kind of control over GC is destined to meet resistance because of the
>> variety of GC schemes and worse, never actually solve the problem, just move
>> it around.
>
> Please don't ignore resistance just because it's getting in the way of what
> you want. Your needs are real, it's just that there's a huge constellation of
> issues that are not immediately obvious in the context of individual
> problems. Language design is all about threading the needle, finding ways to
> address at least some of the issues without suffering from longer term side
> effects.
Oh, I’m not, I’m just accepting reality because of the concerns, which is why
I’m spitballing other ideas. It’s that I completely understand the position of
others, and trying to think about other solutions.
>
>>
>> Yes, this is something really radical that would be years in showing up in
>> any browser. I think for now I'll just have to stick to a lot of
>> pre-allocated globals.
>
> As asm.js shows, you have this already. Your heap is an ArrayBuffer, and
> cannot point to GC things so it will be ignored by the GC. You "just" have to
> manage the space manually. (And you can emscripten-compile a malloc library
> to help out, if you like.)
>
> Typed Objects should go a long way towards making this nicer to use from
> hand-written JS.
I do that now. Everything except locals are globals within my classes, so I
never allocate anything other than numbers or strings; eventually those will
get me, too, but they are quick GC objects.
I keep posting this because I want people to take a look :)
www.klinksoftware.com/ws/ <http://www.klinksoftware.com/ws/> You can see what
I did and get the code from GitHub itself. I actually don’t have any GCs in
there that stop anything, but I know the trouble I went through.
I’d rather not use asm.js, which isn't hand-written code. I, and I suspect a
lot of others, really want to do more real-time code. It’s just that the GC
gets in the way, sometimes. What I’m doing is more of an experiment to see how
far I can push JS. Pretty far, actually.
[>] Brian
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
