Brendan Eich (2013-10-27T14:57:16.000Z)
> Brandon Andrews <mailto:warcraftthreeft at sbcglobal.net>
> October 27, 2013 5:45 AM
> --------------------------------------------
> On Sun, 10/27/13, Domenic Denicola <domenic at domenicdenicola.com> wrote:
>
> Subject: RE: Proposal for new floating point and integer data types
> To: "Rick Waldron" <waldron.rick at gmail.com>, "Brandon Andrews" 
> <warcraftthreeft at sbcglobal.net>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Sunday, October 27, 2013, 12:18 AM
>
> Also
> http://www.slideshare.net/BrendanEich/js-resp/5,
> presented in convenient video form at
> http://www.youtube.com/watch?v=IXIkTrq3Rgg.
>
>
> (I'm not sure how to replay to these. I see people bottom posting 
> usually. Not overly familiar with mailing lists, so I hope this works).

USENET norm applies (bottom posting, AKA top-citing -- and gmail will 
trick people into not trimming their citations, but please do).

> Woah, I didn't see that video when I was searching. (Finding a bunch 
> searching for ECMAscript 7 and 8 and simd now). That's exactly the 
> direction I was hoping JS would go. I was actually typing up SIMD 
> types, but removed it as it seemed too much to request. If they're 
> willing to add all the types and the operators with swizzling support 
> that would probably make JS nearly perfect for computing. (I have a 
> few projects I did in the past which could have used it). I found a 
> gist where someone wrote of a proposal apparently 
> https://gist.github.com/jensnockert/7a0f6a99a0f3bde2facb , looks very 
> well thought out, even including prefetch operations which would be 
> amazing.
>
> Looking at his direction and slides, then single and double in my 
> proposal would be float32, float64 which is more aesthetically similar 
> to the other types. I'm impressed at how well thought out everything 
> is for the future of JS.

http://wiki.ecmascript.org/doku.php?id=strawman:value_objects is the 
place where I will be editing ES7 value objects (shortly; in time for 
the November meeting, I hope). Please excuse the out-of-date material.

John McCutchan's SIMD polyfill, as my slides showed, is at 
https://github.com/johnmccutchan/ecmascript_simd. Emscripten now has a 
branch targeting SIMD intrinsics. Here's what Alon wrote recently:

"""
I've implemented some SIMD support in emscripten, in a branch called 'simd'. Status is:

1. There is a SIMD header, system/include/emscripten/vector.h, which defines float32x4 and uint32x4. They can be used for basic vector operations - load/store, add/subtract/multiple/divide - which LLVM translates into the proper LLVM vector instructions.
2. Emscripten translates LLVM vector instructions into SIMD JS API calls, compatible with the polyfill.
3. Currently some basic tests work, both using the explicit vector types from that new header, and LLVM's autovectorization (which generates the same LLVM vector instructions). (Supporting the vector types in emscripten turned out to be easier than I had anticipated, at least for basic usage.)
4. This does not relate to asm.js yet, I am not sure what the status of SIMD in the type system there is. But for smaller benchmarks that should not prevent us from measuring useful numbers.
5. The emscripten branch does not include the SIMD polyfill code yet (just waiting on a license for me to be able to merge it into emscripten), so the tests don't run out of the box yet, but you can just paste the polyfill at the top of the emscripten output and it should work. (To run the tests, do       EM_SAVE_DIR=1 ./tests/runner.py other.test_simd      or the same with simd2 at the end, output file will be in /tmp/emscripten_temp/a.out.js)
6. The largest testcase I've tried on so far is autovectorization on the Linpack benchmark. I've been in touch with Heidi who has provided some more benchmarks, I think they would need to be converted from the SSE SIMD API into the more generic one, but I am not sure if all those benchmarks need fits in the JS API. Also not sure if we can't 'polyfill' the SSE API (or a part of it) using the simpler JS-compatible one somehow, if that were possible, we could perhaps avoid manually converting benchmarks?
7. Using the explicit float32x4/uint32x4 types in C does not require any special compiler settings. The LLVM autovectorizer on the other hand is off by default, to enable it you need

   --llvm-opts "['-O3', '-vectorize', '-vectorize-loops', '-bb-vectorize-vector-bits=128', '-force-vector-width=4']"

   , see test_simd in tests/test_other.py for an example. I am considering adding an option to emcc such as --autovectorize which would add those 4 instructions, thoughts? (Perhaps it should always be on, once this is stable?)

So overall this is basically at the point where we can start to test compiled C code using the polyfill and/or JS engine support, when ready.

- Alon

"""


> I see the slide with the types he's suggesting.

("he" => me; hello.)

> Are there types for the int8/16/32, and uint8/16/32?
>
> var foo = 0: float32;

No one is proposing type annotations a la ES4 or TypeScript, note well.

Indeed although I call out float32 and int32/uint32, it makes sense to 
have value objects for all the sized int and IEEE-754 floating types.

> On slide 14 he has float32(0) indicating something like the following 
> (or using the literal syntax):
>
> var foo = float32(42);
>
> I was worried about suggesting something like that for compatibility 
> with old code, but if that's the direction and has no issues, then 
> it's perfect. I just realized that Brendan Eich created JS so I assume 
> he fully knows about any compatability issues. His solution is cleaner 
> for conversions.

Thanks :-). You're right that extant code on the Web might use float32 
as a function name, but that's ok. As usual, JS's bindings in the global 
object are writable or otherwise replaceable, to allow user definitions 
to trump emergent built-ins. Object detection, e.g., something like

   if (!this.float32)
     var float32 = function (x) {...};

may fail, but anything object detecting float32 should want what we aim 
to provide here -- if that name were used for a function with a 
different signature and semantics, I'd be sad but we would probably try 
to evangelize such object-detecting content.

It's extremely unlikely that anyone wrote a detection pattern for the 
name 'float32' without anticipating what I've been talking about lately, 
anyway.

Still, I've learned the hard way to never say never on the Web. I've 
seen almost every common name used in the global object's scope, and not 
always as one might expect. If we do run into a hard compatibility 
problem of the object-detection-for-mismatching-signature/semantics 
kind, we can use a built-in module. Indeed it may be better to do that 
anyway, although the typed arrays, Int8Array, etc., are all in global 
scope and require no import. If we do use a built-in module, then you'd 
have to say something like

   import {int8, int16, int32, int64} from "@valueobjects";

where the "@valueobjects" name is a place-holder that may or may not be 
spelled anything like that.

> With what he's proposing how do you perform a bitwise conversion from 
> uint64 to a float64? I think the norm right now is to use the typed 
> array spec with views for 32-bit conversions. (It comes up in a few 
> problems).

See https://github.com/dherman/float.js.

> I assume they're adding Uint64Array and Int64Array with his proposed 
> changes which would provide a solution for the bitwise conversion.

Yes, we want 64-bit scalar and typed-array objects, both.

> I think strong typing would be a really good idea with all of these 
> types flying around. Found a few posts Brendan Eich made about strong 
> typing. Can't figure out how he feels about that. Would static typing 
> ever work for JS? Kind of like a "use static"; with proper all or 
> nothing compilation?

I've written quite a bit about the problems adding static typing to JS 
("strong typing" is ill-defined, it was used by marketeers in the past 
and that hurt). A fairly recent es-discuss thread:

http://esdiscuss.org/topic/optional-strong-typing

Quoting myself:

"ES4 failed in part because of AS3 namespaces (from original JS2/ES4 
namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by 
Common Lisp symbol packages), but also because on the Web it's very hard 
to know /when/ to typecheck. Code loads all the time. Judgments may be 
invalidated down the road. The "any" type requires runtime checking."

/be
domenic at domenicdenicola.com (2013-11-03T22:00:11.984Z)
Brandon Andrews <mailto:warcraftthreeft at sbcglobal.net> October 27, 2013 5:45 AM

> (I'm not sure how to replay to these. I see people bottom posting usually. Not overly familiar with mailing lists, so I hope this works).

USENET norm applies (bottom posting, AKA top-citing -- and gmail will 
trick people into not trimming their citations, but please do).

> Woah, I didn't see that video when I was searching. (Finding a bunch 
> searching for ECMAscript 7 and 8 and simd now). That's exactly the 
> direction I was hoping JS would go. I was actually typing up SIMD 
> types, but removed it as it seemed too much to request. If they're 
> willing to add all the types and the operators with swizzling support 
> that would probably make JS nearly perfect for computing. (I have a 
> few projects I did in the past which could have used it). I found a 
> gist where someone wrote of a proposal apparently 
> https://gist.github.com/jensnockert/7a0f6a99a0f3bde2facb , looks very 
> well thought out, even including prefetch operations which would be 
> amazing.
>
> Looking at his direction and slides, then single and double in my 
> proposal would be float32, float64 which is more aesthetically similar 
> to the other types. I'm impressed at how well thought out everything 
> is for the future of JS.

http://wiki.ecmascript.org/doku.php?id=strawman:value_objects is the 
place where I will be editing ES7 value objects (shortly; in time for 
the November meeting, I hope). Please excuse the out-of-date material.

John McCutchan's SIMD polyfill, as my slides showed, is at 
https://github.com/johnmccutchan/ecmascript_simd. Emscripten now has a 
branch targeting SIMD intrinsics. Here's what Alon wrote recently:


---

I've implemented some SIMD support in emscripten, in a branch called 'simd'. Status is:

1. There is a SIMD header, system/include/emscripten/vector.h, which defines float32x4 and uint32x4. They can be used for basic vector operations - load/store, add/subtract/multiple/divide - which LLVM translates into the proper LLVM vector instructions.
2. Emscripten translates LLVM vector instructions into SIMD JS API calls, compatible with the polyfill.
3. Currently some basic tests work, both using the explicit vector types from that new header, and LLVM's autovectorization (which generates the same LLVM vector instructions). (Supporting the vector types in emscripten turned out to be easier than I had anticipated, at least for basic usage.)
4. This does not relate to asm.js yet, I am not sure what the status of SIMD in the type system there is. But for smaller benchmarks that should not prevent us from measuring useful numbers.
5. The emscripten branch does not include the SIMD polyfill code yet (just waiting on a license for me to be able to merge it into emscripten), so the tests don't run out of the box yet, but you can just paste the polyfill at the top of the emscripten output and it should work. (To run the tests, do       EM_SAVE_DIR=1 ./tests/runner.py other.test_simd      or the same with simd2 at the end, output file will be in /tmp/emscripten_temp/a.out.js)
6. The largest testcase I've tried on so far is autovectorization on the Linpack benchmark. I've been in touch with Heidi who has provided some more benchmarks, I think they would need to be converted from the SSE SIMD API into the more generic one, but I am not sure if all those benchmarks need fits in the JS API. Also not sure if we can't 'polyfill' the SSE API (or a part of it) using the simpler JS-compatible one somehow, if that were possible, we could perhaps avoid manually converting benchmarks?
7. Using the explicit float32x4/uint32x4 types in C does not require any special compiler settings. The LLVM autovectorizer on the other hand is off by default, to enable it you need

   --llvm-opts "['-O3', '-vectorize', '-vectorize-loops', '-bb-vectorize-vector-bits=128', '-force-vector-width=4']"

   , see test_simd in tests/test_other.py for an example. I am considering adding an option to emcc such as --autovectorize which would add those 4 instructions, thoughts? (Perhaps it should always be on, once this is stable?)

So overall this is basically at the point where we can start to test compiled C code using the polyfill and/or JS engine support, when ready.

\- Alon

---


> I see the slide with the types he's suggesting.

("he" => me; hello.)

> Are there types for the int8/16/32, and uint8/16/32?
>
> ```js
> var foo = 0: float32;
> ```

No one is proposing type annotations a la ES4 or TypeScript, note well.

Indeed although I call out float32 and int32/uint32, it makes sense to 
have value objects for all the sized int and IEEE-754 floating types.

> On slide 14 he has float32(0) indicating something like the following 
> (or using the literal syntax):
>
> ```js
> var foo = float32(42);
> ```
>
> I was worried about suggesting something like that for compatibility 
> with old code, but if that's the direction and has no issues, then 
> it's perfect. I just realized that Brendan Eich created JS so I assume 
> he fully knows about any compatability issues. His solution is cleaner 
> for conversions.

Thanks :-). You're right that extant code on the Web might use float32 
as a function name, but that's ok. As usual, JS's bindings in the global 
object are writable or otherwise replaceable, to allow user definitions 
to trump emergent built-ins. Object detection, e.g., something like

```js
if (!this.float32)
   var float32 = function (x) {...};
```

may fail, but anything object detecting float32 should want what we aim 
to provide here -- if that name were used for a function with a 
different signature and semantics, I'd be sad but we would probably try 
to evangelize such object-detecting content.

It's extremely unlikely that anyone wrote a detection pattern for the 
name 'float32' without anticipating what I've been talking about lately, 
anyway.

Still, I've learned the hard way to never say never on the Web. I've 
seen almost every common name used in the global object's scope, and not 
always as one might expect. If we do run into a hard compatibility 
problem of the object-detection-for-mismatching-signature/semantics 
kind, we can use a built-in module. Indeed it may be better to do that 
anyway, although the typed arrays, Int8Array, etc., are all in global 
scope and require no import. If we do use a built-in module, then you'd 
have to say something like

```js
import {int8, int16, int32, int64} from "@valueobjects";
```

where the "@valueobjects" name is a place-holder that may or may not be 
spelled anything like that.

> With what he's proposing how do you perform a bitwise conversion from 
> uint64 to a float64? I think the norm right now is to use the typed 
> array spec with views for 32-bit conversions. (It comes up in a few 
> problems).

See https://github.com/dherman/float.js.

> I assume they're adding Uint64Array and Int64Array with his proposed 
> changes which would provide a solution for the bitwise conversion.

Yes, we want 64-bit scalar and typed-array objects, both.

> I think strong typing would be a really good idea with all of these 
> types flying around. Found a few posts Brendan Eich made about strong 
> typing. Can't figure out how he feels about that. Would static typing 
> ever work for JS? Kind of like a "use static"; with proper all or 
> nothing compilation?

I've written quite a bit about the problems adding static typing to JS 
("strong typing" is ill-defined, it was used by marketeers in the past 
and that hurt). A fairly recent es-discuss thread:

http://esdiscuss.org/topic/optional-strong-typing

Quoting myself:

"ES4 failed in part because of AS3 namespaces (from original JS2/ES4 
namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by 
Common Lisp symbol packages), but also because on the Web it's very hard 
to know /when/ to typecheck. Code loads all the time. Judgments may be 
invalidated down the road. The "any" type requires runtime checking."