Structs (was: Day 2 meeting notes)
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a satisfactory compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist of members that
also are value types. Would structs in future revisions of ECMA-262
share these characteristics?Is it fair to assume that there would end up being a more richer set
of primitives to select from when composing a struct than simply
"object", "boolean", "number", "string" and the like? Again,
ECMA-334 defines the following:en.csharp-online.net/ECMA-334:_11.1.5_Integral_types
Would something similar be envisioned for ECMA-262?
No, we did not envision adding more primitive types, type annotations,
conversion rules, and first-class struct declarations.
Something more like
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:"u32", y:"u32",
z:"u32",
r:"u8", g:"u8", b:"u8",
a:"u8"}));
let a = new TA(...);
... a[i].x ...
Khronos would like to continue developing their API as WebGL host objects in the meantime. This may lead to forking of APIs in the developers' minds. The possible danger is failure to reuse common abstractions.
Need a champion. Waldemar offered to work with Khronos to drive a
proposal.
Dave, Vlad, and Andreas (Vlad is on the WebGL working group and has
implemented WebGL typed arrays in TraceMonkey) are interested in
collaborating too.
If structs are anything like value types, then I am interested in
participating. I'm particularly interested in working through the
details of how arithmetic of integer like quantities would work.
The struct-array idea for WebGL avoids the typed array aliasing
design, and consequent byte-order leakage. But we are not envisioning
new operator overloading or literal syntax. At most a[i].x would be
optimized to a very fast, packed member read or write, after scaling i
and adding the offset of x. Any read would use ES's number type, I
believe.
There's an issue with float32 -- IIRC it does not project into float64
(AKA double). All the other types (uint32, what I schematically named
"u32" above, etc.) do.
On May 27, 2010, at 2:18 PM, Jonas Sicking wrote:
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich <brendan at mozilla.com>
wrote:If structs are anything like value types, then I am interested in participating. I'm particularly interested in working through the
details of how arithmetic of integer like quantities would work.The struct-array idea for WebGL avoids the typed array aliasing
design, and consequent byte-order leakage. But we are not envisioning new
operator overloading or literal syntax. At most a[i].x would be optimized to
a very fast, packed member read or write, after scaling i and adding the
offset of x. Any read would use ES's number type, I believe.The other thing that Khronos really wanted to avoid was for a[i] in the above expression not to create an object which is to be initialized and GCed. Though maybe you're including that in the scaling+offset algorithm.
Yes, I wrote a[i].x on purpose. Just a[i] with no .x or .y, etc. after
would reify a JS object.
With typed arrays, you have to make two views of the array I sketched,
one a uint32 array and the other a uint8 array, and use them both to
load and store the appropriate "members": x, y, and z are via the
uint32 view, r/g/b/a are via the uint8 view. But there is no "struct"
or ensemble of all 16 bytes that you can load and store efficiently
with typed arrays.
Same with the struct-schema idea.
On May 27, 2010, at 2:55 PM, Brendan Eich wrote:
With typed arrays, you have to make two views of the array I
sketched, one a uint32 array and the other a uint8 array, and use
them both to load and store the appropriate "members": x, y, and z
are via the uint32 view, r/g/b/a are via the uint8 view. But there
is no "struct" or ensemble of all 16 bytes that you can load and
store efficiently with typed arrays.Same with the struct-schema idea.
But, I should have added, with the struct-schema idea, at least you
can reify an object representing the whole struct. Which I think is
winning, even if it's a low-perf path. The typed array aliasing has no
such aggregate view AFAIK.
Someone might object that this is a footgun, but performance-minded
hackers know how to avoid slowdowns. And apples-to-apples comparison
with typed arrays only ever loads or stores the primitive-typed
fields, not whole structs.
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich <brendan at mozilla.com> wrote:
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a satisfactory compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist of members that also are value types. Would structs in future revisions of ECMA-262 share these characteristics?
Is it fair to assume that there would end up being a more richer set of primitives to select from when composing a struct than simply "object", "boolean", "number", "string" and the like? Again, ECMA-334 defines the following:
en.csharp-online.net/ECMA-334:_11.1.5_Integral_types
Would something similar be envisioned for ECMA-262?
No, we did not envision adding more primitive types, type annotations, conversion rules, and first-class struct declarations.
Something more like
const TA = Array.newTypedArray(fixed_length, Object.newStructType({x:"u32", y:"u32", z:"u32", r:"u8", g:"u8", b:"u8", a:"u8"})); let a = new TA(...);
... a[i].x ...
Khronos would like to continue developing their API as WebGL host objects in the meantime. This may lead to forking of APIs in the developers' minds. The possible danger is failure to reuse common abstractions.
Need a champion. Waldemar offered to work with Khronos to drive a proposal.
Dave, Vlad, and Andreas (Vlad is on the WebGL working group and has implemented WebGL typed arrays in TraceMonkey) are interested in collaborating too.
I'd also like to collaborate on this and offer one additional point: for WebGL's use case, we will need to be able to query the byte offsets of fields in these structs as well as the byte size of the struct. This is needed in order to make the appropriate OpenGL calls to set up rendering after the data has been assembled and uploaded to the graphics card.
On 05/25/2010 07:09 PM, Waldemar Horwat wrote:
Structs in ECMA-334 are value types, and consist of members that also are value types. Would structs in future revisions of ECMA-262 share these characteristics?
Is it fair to assume that there would end up being a more richer set of primitives to select from when composing a struct than simply "object", "boolean", "number", "string" and the like? Again, ECMA-334 defines the following:
en.csharp-online.net/ECMA-334:_11.1.5_Integral_types
Would something similar be envisioned for ECMA-262?
If structs are anything like value types, then I am interested in participating. I'm particularly interested in working through the details of how arithmetic of integer like quantities would work.