On 10/31/2014 08:40 AM, Katelyn Gadd wrote:
In my testing, even best-case optimized memcpy/memset loops did not
produce the kind of efficient code you want. There were always bounds
checks and in some cases I saw other overhead. The set/copy definitely
weren't vectorized. In the best case I
Luke Wagner wrote:
the proposed ArrayBuffer.prototype.discard
I'll get this on the November Agenda.
/be
These two methods happen to fix one of the two reasons I haven't
*really* dabbled in handwritten asm.js (the other being the lack of
string handling).
--
Isiah Meadows
Steve Fink wrote:
On a related note, I*would* like to have some way of getting the OS to
decommit memory. Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=855669
(start reading at about comment 22) for our discussion and attempt at
this, which looks like it mysteriously trailed off this
On 11/04/2014 11:08 AM, Brendan Eich wrote:
Steve Fink wrote:
On a related note, I*would* like to have some way of getting the OS to
decommit memory. Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=855669
(start reading at about comment 22) for our discussion and attempt at
this, which looks
Steve Fink wrote:
I'm not sure we're talking about the same thing. I'm talking about what
would be madvise(MADV_DONTNEED) on POSIX or VirtualAlloc(MEM_RESET) on
Windows. Er... actually, I think it would be MEM_RESET followed by
MEM_COMMIT to get the zero-filling while still releasing the
ArrayBuffer.transfer provides a coarser granularity than the proposed
ArrayBuffer.prototype.discard in bug 855669. Page-level madvise(MADV_DONTNEED)
is the type of thing you'd want if you were implementing a malloc heap
(jemalloc being an example). OTOH, ArrayBuffer.transfer also allows you
From: Andreas Rossberg rossb...@google.com
To: Katelyn Gadd k...@luminance.org
Cc: es-discuss es-discuss@mozilla.org
Date: Mon, 3 Nov 2014 08:54:16 +0100
Subject: Re: typed array filling convenience AND performance
On 31 October 2014 16:40, Katelyn Gadd k...@luminance.org wrote:
I'd also
On 31 October 2014 16:40, Katelyn Gadd k...@luminance.org wrote:
I'd also like to chime in since this is a real problem for
performance-sensitive JSIL code:
The idea that JS runtimes will just optimize all our
performance-sensitive loops is lovely. It also appears to be a
fantasy, because
I'd also like to chime in since this is a real problem for
performance-sensitive JSIL code:
The idea that JS runtimes will just optimize all our
performance-sensitive loops is lovely. It also appears to be a
fantasy, because we've been writing those loops for years and
they're still slow. I did
The usecases:
*1) Filling with custom data*
When writing WebGL or physics or many other things todo with large
collections of data, it's not unusual to have to fill arrays with custom
data of some kind.
someArray.set([
x0, y0, 1, 0, 0,
x1, y0, 0, 1, 0,
x1, y1, 0, 0, 1,
x0, y0, 1, 0, 0,
+1 - especially the lack of something like the proposed memset() has been a
massive headache for me.
Semantics (I'm quite nitpicky on them)... I'd prefer the argument order for
memcpy() to be (src, dstOffset, srcOffset, size) to be consistent with
set(). As for memset(), I'd prefer (value,
Have you looked at the ES6 typed array constructor
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-%typedarray%-intrinsic-object
and instance methods
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-%typedarrayprototype%-object
In
On Thu, Oct 30, 2014 at 3:14 PM, Adrian Perez de Castro ape...@igalia.com
wrote:
On Thu, 30 Oct 2014 09:29:36 +0100, Florian Bösch pya...@gmail.com
wrote:
The usecases:
[...]
*3) Initializing an existing array with a repeated numerical value*
For audio processing, physics and a
On Thu, Oct 30, 2014 at 1:41 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Performance optimizatiuon in an implementation issues. That’s where you
should apply performance pressure.
That's true, but if there's only bad APIs to do certain tasks, it doesn't
help.
On 10/30/2014 06:14 AM, Adrian Perez de Castro wrote:
On Thu, 30 Oct 2014 09:29:36 +0100, Florian Bösch pya...@gmail.com wrote:
The usecases:
[...]
*3) Initializing an existing array with a repeated numerical value*
For audio processing, physics and a range of other tasks it's important
On Oct 30, 2014, at 10:44 AM, Steve Fink sph...@gmail.com wrote:
On 10/30/2014 06:14 AM, Adrian Perez de Castro wrote:
On Thu, 30 Oct 2014 09:29:36 +0100, Florian Bösch pya...@gmail.com wrote:
The usecases:
[...]
*3) Initializing an existing array with a repeated numerical value*
On Thu, Oct 30, 2014 at 6:44 PM, Steve Fink sph...@gmail.com wrote:
Now there is %TypedArray%.prototype.fill. But I've become generally
skeptical about it as an answer to performance concerns. I would rather
see engines hyperoptimize
for(var i=0; isize; i++){ someArray[i] = 0; }
based on
17 matches
Mail list logo
