I'm a half lurker, as I've participated and thrown out ideas.
I've embedded javascript as a scripting languages outside the web, in
both personal and non-personal projects. I've used Javascript to write
games or experiments just to amuse myself, and this is coming from a
person who still beli
trouble than types", then you said " types would be a great help".
I'm sure I just misunderstood what you meant.
Anyway, I think types are a great help in many cases and wouldn't
compromise the dynamic-ness of JavaScript whenever required!
On Tue, 16 Jan 2018 at 20
My 2 cents from a pure developer (not js engine implementer.) I've been
developing for decades, started with assembly, to C, to C++ and Java,
and lately have been fascinated with javascript, especially as it's run
anywhere.
I'm developing both a 3D shooter where every bit of content (maps,
m
7;t help performance much in practice. Similarly, standard arrays with just
> numbers are almost as fast as typed arrays as well, so unless you're in
> serious performance critical, likely asm.js, code, you might get a 0.5% boost.
>
>
> On Mon, Jun 20, 2016, 11:20 Brian Barn
As far as I can read, Typed Objects/Structs are in consideration for a
later version of ecmascript (but not in the spec) and there exists some
implementations. It depends on the engine, but has there been any
thought to how costly they might be to fake at least some rudimentary
type support?
On Fri, May 13, 2016, 13:14 Brian Barnes mailto:gga...@charter.net>> wrote:
On May 13, 2016, at 12:13 PM, /#!/JoePea mailto:j...@trusktr.io>> wrote:
> Or "Cython in Javascript". I think your needs can be satisfied by
C/C++ addons in Node.js or WebAssembly i
> On May 13, 2016, at 12:13 PM, /#!/JoePea wrote:
>
> > Or "Cython in Javascript". I think your needs can be satisfied by C/C++
> > addons in Node.js or WebAssembly in browser
>
> But we want to stay in JavaScript because we like the language. Plus, writing
> a framework in JavaScript has the
> On May 13, 2016, at 12:23 PM, Herby Vojčík wrote:
>
> It's different. Does _allocation_ or _GC_ eats the performance?
That’s a good question. It’d be hard to tease out that data for runs of the
source, but I suspect it’s GC, because it’s a pause, not an overall slowdown.
And over-all paus
rage" functions are not inlined.
>
>
> On Fri, May 13, 2016 at 3:09 PM, Herby Vojčík wrote:
>>
>>
>> Brian Barnes wrote:
>>>
>>> It could be, but there is a difference between:
>>>
>>> var x;
>>>
>>> and:
&
> On May 13, 2016, at 11:09 AM, Herby Vojčík wrote:
>
>
>
> Brian Barnes wrote:
>> It could be, but there is a difference between:
>>
>> var x;
>>
>> and:
>>
>> this.x
>
> You should probably do `var x = XPool.get();` and at
Certainly, I’d love webassembly, but as of now, it’s not something that’s part
of the spec, or something that I can use right now, and I also want to see how
far I can push the language as an experiment.
I think there is a place for improving the language as is; it’s surprising how
far javascri
, so a super hoist would
just eliminate a lot of hard to read code I’ve written!
[>] Brian
> On May 13, 2016, at 10:43 AM, Alan Johnson wrote:
>
> Sounds like a potential JS engine optimization, rather than a language
> feature per se.
>
>
>> On May 12, 2016, at 1
Wirfs-Brock wrote:
>
>
>> On May 12, 2016, at 9:39 AM, Brian Barnes wrote:
>>
>> ...
>> If I call doSomething a lot of times, I get a lot of objects to be tracked
>> and GC’d. Yes, I can rewrite that code to obviously eliminate them, but
>> pretend t
Another idea I had, something I do all the time but would be interesting to see
in a syntactical sugar approach. Again, almost all this is because I (and many
others) are writing real time, GC-sensitive applications (in my case a
auto-generated first person shooter, every bitmap, every surface,
A note on this from somebody who's entire existence seems dedicated to
stopping as much stuff as possible from getting GC'd, the example below:
>const u = new Point(5, 10);
>const v = new Point(1, -2);
>
>const w = u + v; // desugars to u[Symbol.add](v)
>console.log(w); // { x: 6, y: 8 };
Co
That's a good point, "temp" would be a bad keyword.
Again, just throwing some things out there to see what kind of
discussion comes about. My goal is to find a way that hand-crafted
javascript (i.e., not cross-compiled asm.js) could potentially avoid GC
and can be compiled without needing to
optimised anyway by escape analysis without special
> syntax.
>
> On 23 Mar 2016 11:13 p.m., "Brian Barnes" <mailto:gga...@charter.net>> wrote:
> Another of my "throw ideas at the wall to deal with high performance code in
> a GC world.” Thanks for put
Another of my "throw ideas at the wall to deal with high performance code in a
GC world.” Thanks for putting up with this!
A new variable declaration keyword “temp” that declared variables that are:
1) Stack based
2) Locked to their declared type
I know engines probably do some of this work al
I know properties on classes are getting a look over for the next
iteration (last I checked) and I understand javascript is obviously a
different language then other oo languages with a different foundation,
but I bring this up for it's usage in producing stricter code that
reduces errors and i
gt; wrote:
Already considered and to be implemented via strong mode IIRC.
On 18.03.2016 14:36, Brian Barnes wrote:
I know properties on classes are getting a look over for the
next iteration (last I checked) and I understand javascript is
obviously a different lang
away the
`let`s and seal it, and you got:
```js
"use strict";
class Test {
x = 1;
y = 2;
constructor() {
Object.seal(this);
this.z = 3; // TypeError
}
}
```
You can already use this using transpilers (at least babel supports it).
On 18.03.2016 15
Fri, Mar 18, 2016 at 8:36 AM, Brian Barnes mailto:gga...@charter.net>> wrote:
I know properties on classes are getting a look over for the next
iteration (last I checked) and I understand javascript is
obviously a different language then other oo languages with a
different f
> On Mar 14, 2016, at 12:28 PM, Steve Fink wrote:
>
> Well, "the most aggressive compilation" is undecidable in general, since you
> can't predict the future to know if some future execution won't invalidate
> this or that constraint. But sure, I think we're basically agreeing, except
> that I
> On Mar 14, 2016, at 12:52 PM, Steve Fink 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
I think that's a good, workable solution, and would help with my
specific problem.
[>] Brian
On 3/14/2016 10:43 AM, Boris Zbarsky wrote:
On 3/13/16 10:43 PM, Brian Barnes wrote:
1. Potential mis-use of API could make things slower
2. People assuming things could freeze behavior
3
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
> On Mar 13, 2016, at 11:21 PM, /#!/JoePea wrote:
>
> That sounds like a good idea, being able to hint to the browser when
> is a good point to GC, and also when to avoid GC if possible.
>
> Idea: Maybe we have an animation that last 500 ms. Before the
> animation, we can call `System.preventGC(
Boris, I think we’re going in a couple circles here, so let’s not waste anymore
time (though it’s a fascinating discussion.) I think you’re complaints come
down to:
1. Potential mis-use of API could make things slower
2. People assuming things could freeze behavior
3. People will assume behavio
> On Mar 13, 2016, at 5:22 PM, Steve Fink wrote:
>
>> This is a good time to bring up the other half of my original email because
>> a number of other people have chimed in with their experiences with GC when
>> attempting to develop more time critical applications without stutter.
>
> I reall
Boris wrote:
> Having explicit types would help with this, of course.
I think that’s the key. As you and Steve note, the slower paths are the ones
that gather information on what the types are retained by the variables; and
that helps in the compilation phase. So really, for this to be useful
> On Mar 13, 2016, at 5:16 PM, Boris Zbarsky wrote:
>
> On 3/12/16 10:52 PM, Brian Barnes wrote:
>>> What I'm trying to say is that it may well not, if it just called JS_GC and
>>> if the problem to be solved is pauses on the order of several tens to
>>&g
This is a good time to bring up the other half of my original email because a
number of other people have chimed in with their experiences with GC when
attempting to develop more time critical applications without stutter.
The second part was a hint to tell the engine to always take the most
ag
> On Mar 13, 2016, at 6:27 AM, Florian Bösch wrote:
>
> I'd like to chime in here on the GC. I make my living writing WebGL code for
> a living. JS'es stop-the-world mark&sweep for however long it takes approach
> to GC'ing is very troublesome.
>
> A new frame has to be produced every 16.6ms (
> On Mar 12, 2016, at 10:32 PM, Boris Zbarsky wrote:
>
> On 3/12/16 10:22 PM, Brian Barnes wrote:
>> We’re closing in on something! This could have been clearer on my end;
>> I am looking at only javascript objects. My code, for instance,
>> interacts only thoug
> On Mar 12, 2016, at 10:05 PM, Boris Zbarsky wrote:
>
> On 3/12/16 9:52 PM, Brian Barnes wrote:
>> This is key:
>>
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
>>
>> When the mozilla docs refer to GC, they refer to m
> On Mar 12, 2016, at 9:31 PM, Boris Zbarsky wrote:
>
> On 3/12/16 9:11 PM, Brian Barnes wrote:
>> The contract would be, if the engine is GC (which is likely, as I pointed
>> out without compiling or additions to the language), then do as much clean
>> up as possibl
here...
> }
> ```
>
> but, engine heuristics might be better able to choose more appropriate times
> to collect. And, only really makes sense for synchronous code
>
>> On Mar 12, 2016, at 8:52 PM, Boris Zbarsky wrote:
>>
>>> On 3/12/16 8:08 PM, Brian
> On Mar 12, 2016, at 8:52 PM, Boris Zbarsky wrote:
>
> On 3/12/16 8:08 PM, Brian Barnes wrote:
>> As for being a de-optimization hazard, that’s certain a problem, but we
>> shouldn’t disallow the usage of something because programmers are bad.
>
> It's not
, and
large gcs. A callback would solve any concurrency problems, and probably make
a better system. It leaves the implementations details out of the hands of the
user code.
[>] Brian
> On Mar 12, 2016, at 7:45 PM, liorean wrote:
>
>> Am 12.03.2016 um 07:27 schrieb Brian Barnes
For the last couple months I’ve been working on a “how doable is it” project —
it’s a complete 3D shooter in Javascript — but where every piece of it — every
pixel in every texture, every tangent space, every polygon, and even every
sound — is dynamically generated.
I have an early alpha. You
40 matches
Mail list logo
