HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tc39
ecmascript_simd
JavaScript2013–2026
tc39 / ecmascript_simd · Archived

ecmascript_simd

SIMD numeric type for EcmaScript

Web DevelopmentSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
14Distinct people
15Mentions
0Explicit recommenders
546GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

SIMD numeric type for EcmaScript

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2013-10-15 17:38:33 UTC to 2026-09-24 01:50:27 UTC.

012342013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC404
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

15 sources
suplexer·Sep 24, 2026
1) Google Sheets use case Long story short they are comparing the performance of server-side Java to client-side JS (Java transpiled through GWT/J2CL). So something like: Java -> Hotspot -> native vs Java -> GWT/J2CL -> JS -> V8 (in Chrome) -> native Apples to oranges. They then used J2CL (I presume, not clear from the article) to port Java to Wasm and eventually got around 66% of the server-side Java performance. The Wasm performance story also was nowhere near straightforward - hence the immense efforts spent on optimizing WasmGC and validating the transpiler output. The root of the problem is likely the GWT/J2CL transpiler output. There shouldn't be that much of a peformance drop off between to high-level languages if you're transpiling with speed in mind. I bet there are probably lots of expense runtime checks in the generated output
Read the rest
, among others things. 2) Amazon Prime Video use case Blog seems mostly fine on the surface. But my complaints are always the claims about the limits of performance one could get from a JS-based system - especially in environments where you can call out into native audio/visual libraries. "In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript." What does the JS versus Rust code look like? Are they using the similar libraries/graphics apis/techniques? Did they exhaust every possible low-level tool in JS (Worker Threads, SharedMemory, etc). I feel there are a also rainbow of optimization opportunities available if one controls V8 and the underlying C++ stack. Not that their eventual Wasm architecture is bad per se, it's just layering Rust+JS -> Wasm/C++ is much more complex than simply JS -> C++ back and forth. As a side note, it very annoying that SIMD was taken out of development for JS. Big TC39 wants wants JS to fail. https://github.com/tc39/ecmascript_simd
In The JavaScript Midlife Crisis
flohofwoe·Jan 16, 2025
There's a couple of different sides to the story: - Both WASM and asm.js don't incur JS garbage collector overhead, but it's also possible to write (mostly) garbage-free Javascript by hand. - Both WASM and asm.js don't use Javascript objects or strings (only numbers), and especially not JS objects where the interior structure changes randomly - which in turn might cause JIT recompiles, but it's also possible to write such 'static' Javascript by hand, especially when using Typescript. That's basically about the claim 'Javascript performance can be close to WASM'. It's possible to write JS manually which is 'optimization-friendly', but is not necessarily idiomatic JS - the extreme version of this optimization-friendly JS is asm.js, but nobody would want to write that by hand. Then of course WASM pushes the optimization wall a bit further th
Read the rest
en what's possible with JS, which may increase the performance gap in very specific situations: - WASM has native 64-bit integers (JS has BigInt now, but I don't know if they optimize as well under the hood) - modern WASM has SIMD instructions, which was once an ECMAScript proposal, but has been abandondend in favour of WASM SIMD: https://github.com/tc39/ecmascript_simd Finally there's the historical angle (e.g. "why does WASM exist in the first place"): TL;DR: - with the end of native plugins, Java and Flash in the browser, people were looking for new alternatives to Javascript in the browser - around 2008(?) Emscripten demonstrated that compiling C/C++ to a subset of Javascript can give surprisingly good performance - this subset was then formalized into asm.js and browsers started to add specific optimizations for that subset (via "use asm") - but this JS subset was a dead-end in the long run because requirements for a "Javascript-as-compile-target" clashed more and more with "Javascript-as-programming-language" - ...so a split was made and WASM was created, from now on, Javascript could focus again to be a programming language, and WASM could focus on being a compile target I guess that's it...
In Is WebAssembly Memory64 worth using?
hajile·Mar 4, 2021
Bytecode caching has been a browser feature for years[0] JS has atomics and shared memory arrays which also basically bypass garbage collection [1] JS had working simd.js implementations in both Firefox and Chrome until they were pulled in favor of WASM [0] https://v8.dev/blog/code-caching-for-devs [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://github.com/tc39/ecmascript_simd https://blog.mozilla.org/javascript/2015/03/10/state-of-simd... https://01.org/blogs/2014/bringing-simd-javascript
In Flutter 2
pluma·Jun 4, 2017
This seemed shocking as I thought SIMD was still on track for inclusion in the next ECMAScript release as the proposal was on stage 3 the last time I checked (stage 4 means "it's in the spec", so stage 3 generally means "shipping ASAP"). I first thought Google had single-handedly decided to violate the spec. However it turns out the SIMD proposal has been dead since at least April: https://github.com/tc39/ecmascript_simd/commit/c6ca655dcbfc0... So this isn't really "Google kills SIMD" but "Google kills implementation of dropped proposal". It's still surprising to see proposals get canned this late into the process. The only other example of a late-stage retraction I can think of is Object.observe, which was originally expected to become part of the 2016 edition: https://esdiscuss.org/topic/an-update-on-object-observe
In Google removes SIMD.js support from Chromium
sunfish·Jan 11, 2016
Thanks for the suggestions! FMA is definitely something we want to add. The question is what to do when hardware doesn't have FMA, as it's quite expensive to compute manually. Some applications would want to fall back to discrete multiply and add, but of course that rounds differently and other applications don't want implicit rounding differences between platforms. I believe the solution is to give applications a say in what happens, though the details are still being discussed. The load-and-deinterleave/store-and-interleave operations are good ideas too. They're a little more complex than we could accommodate the initial version of SIMD.js, but they're definitely things we should consider. Working with 8-bit and 16-bit data is an area where the current version of SIMD.js is fairly limited overall. Extending loads are a good idea, and in
Read the rest
general I'm hoping a future version of SIMD.js will provide a much more complete set of operations. I'm interested in any other ideas you have as well. SIMD.js is being developed at https://github.com/tc39/ecmascript_simd and you're welcome to file issues to send us your ideas. Thanks!
In Intent to implement WASM in v8
mkishi·May 22, 2015
They list Intel's contribution extensively in the post. I'm not sure why you'd assume they are trying to deceive anyone. > Intel has been contributing to Chakra, the JavaScript engine for Microsoft Edge > Some examples of Intel’s direct contributions to Chakra’s JIT compiler include better instruction selection and scheduling. > [they] also helped us identify opportunities of missed redundant instruction elimination, and inline overhead reduction. > Intel engineers are collaborating with us closely to implement Single Instruction Multiple Data (SIMD) [1], a future ECMAScript proposal, in Chakra > Intel recently contributed an optimization to improve navigation (load) time for pages containing several inline elements, optimizations to reduce DOM parse times for text-area elements, and participated in investigations and root cause analysis
Read the rest
to improve page load/response times [1]: https://github.com/johnmccutchan/ecmascript_simd [2]: https://github.com/tc39/ecma262
In Intel’s contributions in Microsoft Edge: SIMD and other performance enhancements
BrendanEich·Mar 25, 2015
Good for lulz, but this is really uninformed, if not made up from whole cloth. The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out, John did the Dart work and then worked on https://github.com/johnmccutchan/ecmascript_simd; I had some small helpful role to do with the project involving Mozilla and Intel, too) and the courage and validation -- not the idea, which pre-dates Dart -- of giving the for (let...) loop a binding per iteration in ES6 as in Dart, there has been no influence or help from Dart. Modules in ES6 have nothing to do with Dart, and the work started in 2010, well before Dart ("Dash") leaked. Classes too pre-date Dart, in some ways they go back to JS2/ES4 of the 1999-2003 era, and ES4 of the 2006-8 era. CoffeeScript owes a lot to Ruby and Python, of course, and I did design-champion fat arrow functio
Read the rest
ns into ES6, inspired in part by CoffeeScript. ES6's for-of loop is responding to the same gravity-well as CoffeeScript's for-of, but it differs in substantial aspects. And so on. Languages influence one another -- news at 11 -- but Dart did very little intentional uplift work for JS. SIMD is the big and very good exception to this norm. Better late than never, I say. Now is a good time to help get value objects including bignums into ES7. https://code.google.com/p/dart/issues/detail?id=1533
In “We have decided not to integrate the Dart VM into Chrome”
bhouston·Mar 25, 2015
I think Dart is sort of like CoffeeScript in that it was an experiment and influenced a lot of JavaScript standards people. A lot of the features of CoffeeScript are being integrated into JS with ES6 and ES7. The same is actually happening to the unique features of Dart such as typing and SIMD and better modules. Typing is so cool: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects SIMD is amazing: https://github.com/johnmccutchan/ecmascript_simd So, thank you Dart for showing us the way! My only worry is that the innovators behind Dart are going to be stuck on the Dart project while JavaScript gains their features and even more momentum. I would suggest that they let Dart die and not be stuck with it for years after it has stopped being relevant -- that would be a waste of their talents as they did really see what the future
Read the rest
would be.
In “We have decided not to integrate the Dart VM into Chrome”
azakai·Oct 30, 2014
There are lots of issues, can take a while to find all the use cases in them (work has been ongoing for some time). But from memory I can recall that https://github.com/johnmccutchan/ecmascript_simd/issues/59 is interesting here, it mentions, among other things, the major SIMD-using code portion from an important real-world codebase (IMVU). Might also be relevant discussion on the emscripten repo, https://github.com/kripken/emscripten/issues?q=is%3Aopen+is%... as some debate happened there while implementing code generation that emits SIMD.js.
In Introducing SIMD.js
azakai·Oct 30, 2014
I think you're rushing to judgement pretty quickly here. For example, > 2. Identify proper use cases. The example are quite bogus currently. They show a mandelbrot. That's just one tiny demo. See the github repo discussions for lots of debate on use cases, https://github.com/johnmccutchan/ecmascript_simd/issues This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free to join in as well. In general, while I sympathize to some extent with you and the Apple position here, you are fighting a strong trend in the industry. C has a SIMD API, C# has SIMD API, Dart has a SIMD API, etc. - all those were created for good reasons. Autovectorization would be great - hopefully Apple can prove it beats the API approach - but no compiler has proven it thus far, hence SIMD APIs in all those languages I me
Read the rest
ntioned.
In Introducing SIMD.js
ahoge·Jun 11, 2014
Check "Bringing SIMD to the Web via Dart" by John McCutchan: https://www.youtube.com/watch?v=CKh7UOELpPo He's also the guy wrote the proposal for ECMAScript: https://github.com/johnmccutchan/ecmascript_simd Also, using SIMD is way easier than using shaders. You just write something like this: double average (Float32x4List list) { var n = list.length; var sum = new Float32x4.zero(); for (int i = 0; i < n; i++) { sum += list[i]; } var total = sum.x + sum.y + sum.z + sum.w; return total / (n * 4); } Instead of: double average (Float32List list) { var n = list.length; var sum = 0.0; for (int i = 0; i < n; i++) { sum += list[i]; } return sum / n; }
In Intel Bringing SIMD to JavaScript

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.