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.)
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.
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.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
